Re: [Lilypond-auto] Issue 2658 in lilypond: wrong stem rendering (inconsistent thickness)

[lilypond]

Comment #44 on issue 2658 by address@hidden: wrong stem rendering  
(inconsistent thickness)
http://code.google.com/p/lilypond/issues/detail?id=2658

Bad news.  I've tried some experiments to see how ps2pdf would transfer  
setstrokeadjust to PDF and how it affects typesetting.  Attaching the  
experimental file I worked with.  From left to right, there are four  
staggered boxes each drawn with a) default style of strokeadjust (printed  
to terminal, too) b) strokeadjust set to true c) strokeadjust set to  
false.  Four staggered boxes why?  To get different vertical and horizontal  
offsets.

There are three vertical systems.  The bottom uses rectstroke, the middle  
one uses the equivalent discrete strokes, the top system uses the  
equivalent discrete strokes, but with strokepath fill newpath instead of  
stroke.

Called with
gs -dGraphicsAlphaBits=1 test.ps
we get the straight black and white rendition.  As expected, the default of  
strokeadjust (left and right) looks best.  Without antialiasing, the  
strokepath+fill combination is perfectly equivalent to stroke according to  
the PostScript specification.

Except that it isn't.  There are bumps at some corners in the  
strokeadjusted rectangles.

Now lets start antialiasing, first with -dGraphicsAlphaBits=2 and see where  
we get.
The lower two lines look pretty much indiscriminately bad now, with stroke  
adjustment not helping noticeably.  The top row (using filled paths)  
retains its corner bumps with strokeadjustment but gets the thickness  
nicest.

Taking the default of -dGraphicsAlphaBits=4, we arrive at the version more  
or less corresponding with the proposed defaults.  The "stroke adjusted"  
rectangles in the lower rows have been considerably _fattened_ contrasted  
with the not-strokeadjusted ones and are at best a tiny bit more consistent  
in thickness.  The top row looks pretty unimpressed in the strokeadjusted  
versions (including corner bumps, but those are smoothed to some less  
obvious gray level), but get irregularly thick in the non-strokeadjusted  
version in the middle.

So in short: an inconsistent bunch of horsehockey not even meeting the  
PostScript specs when switching off antialiasing.

Now is that the end of it?  We run ps2pdf on the file (which duly  
outputs "false", telling us that the default of strokeadjustment accessible  
during conversion, whatever it may be worth, is off).

There is some positioning magic in the file intended to make all vertical  
starting positions be different by whole pixel numbers to make rows  
comparable.  This magic is resolution-dependent and does not transfer to  
the PDF, so rendering differences in the two lower rows are expected  
regarded the vertical positioning.

However, the results can be called nothing but appalling.  When calling
gs -dGraphicsAlphaBits=1 test.pdf
on the resulting file, the lower row looks unilaterally reasonable  
independent of the strokeadjust setting.  The middle row (drawn with the  
presumably equivalent strokes) has several uneven strokes in the left 8  
squares drawn without strokeadjustment.  It would appear that rectstroke  
_always_ uses strokeadjustment here regardless of the setting, while the  
explicit strokes obey the setting.  Top row is consistently irregular.

Now what with
gs -dGraphicsAlphaBits=4 test.pdf ?

Bottom row fuzzy and consistently too thick.  Middle row partly fuzzy, with  
the right strokeadjusted squares being consistently fuzzy and too thick,  
and the non-strokeadjustes squares having several unexpectedly sharp  
borders.  The top row is slightly sharper, with not much of a noticeable  
difference between stroke adjustment (maybe a tiny bit sharper/lighter) and  
not.

Conclusion?  Ghostscript significantly changes the available information  
when converting from PostScript to PDF.  And even before converting to PDF,  
its rasterization does not conform to PostScript rendering specifications.   
Not even if we switch off antialiasing and stroke adjustment.

Where does that leave us?  No really good idea.  For direct rasterization,  
I like the strokepath/fill solution with antialiasing best, but for best  
print results, strokeadjustment should likely be left at its default  
of "off".  That drawing a rectangular path using rectstroke gives different  
(and apparently automatically stroke-adjusted) results when converted to  
PDF from stroking a rectangular closed path is a catastrophic failure.  I  
have no good proposal how to work around this.

All of this is tested using Ghostscript 9.07.  One thing that appears clear  
to me is that if we want to produce the best PDF we can, we need to remove  
ps2pdf from our process.  It is supposed not to change the contained  
information, but it does not even manage that.

I'm not sure how to progress regarding the rest.  Considering the large  
inconsistencies, it might be best to leave the strokeadjust parameter at  
its default setting, whatever that may be.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings