GNOME Bugzilla – Bug 747212
Patterns (e.g., /////) use too thin and too closely spaced lines
Last modified: 2015-04-04 19:16:33 UTC
The Patterns tab on ../samples/object-tests.gnumeric uses all our patterns. Unfortunately the pretty much look identical. The lines in patterns like ///// are too thin and too closely spaced.
(They may have been fine in the era of 640x480 displays. That's a while ago.)
We might use only the svg definition of the patterns. Anyway, I think the lines are too large in the diagonal svg patterns.
Using the svg might be expensive. Could we generate the bitmaps (from svg or code) at runtime at a convenient size at runtime?
Well, not sure we can do that esaily because of the many colors combinations.
I'll have a go at it.
Done, at least for screen. Please confirm that the on-screen patterns look reasonable for you. Right now we create a pattern of size 6x6 - 16x16. This is done in order to ensure that lines have the same width and spacing no matter what direction that point. I don't see why we cannot do something similar for other forms of output, basically pdf and svg. The cairo drawing should be totally generic.
As an experiment I made go_pattern_create_cairo_pattern use create_direct_pattern unconditionally for non-solids. Selecting the semi-circle filled object of the test file and printing to svg produces a smaller svg file than the one with the regular svg code. Inkscape is unhappy with both in the identical way: File display/nr-arena-item.cpp line 323 (?): Assertion item->state & NR_ARENA_ITEM_STATE_BBOX failed Firefox shows them close to identically, although the code with the direct rendering code has a darker red, probably because the lines used are a tad thicker. Firefox allowed zooming either and the semi-circles are nice and smooth. Conclusion: we no longer need the special svg code. Jean: agree?
Looks good, at least for screen and pdf. If I print the whole page to svg, firefox and inskape don't show anything. That might be a cairo bug.
I have narrowed that down a bit: When the page contains the two first ovals, firefox is happy. When the page contains the three first ovals, firefox is unhappy. These are all solid fill patterns -- the new code is not involved. When loading the three-oval file in Emacs, only the first two are shown. For what that is worth.
Correction: Emacs shows all three, but the third one is right on top of the first and thus not really visible. It's legend is also on top of the first one's. Anyway, the problem is that when we go from two to three we need multiple pages. Cairo then wraps things in <pageSet> <page> ... </page> <page> ... </page> </pageSet> ...which makes firefox unhappy. That's a problem surely unrelated to patterns.
pageSet is svg 1.2; firefox does not support that. (Nor do any of the other major browsers, I believe.) There's no obvious alternative to cairo using pageSet, so we cannot really blame cairo.
Agreed, when printing six pages on one, I see all shapes, but the legends are unreadable.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.