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

[lilypond]

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

Ok, here is the current choice I see.  Basically it is between leaving  
things as-is, possibly with window dressing, or going to patch set 7 or  
patch set 8.

Things as-is:
  bad looks in typical PDF previewers (overthick stems), somewhat  
unpredictable thickness of stems in print, consistent thickness of staff  
lines in print, single pixels/edges sticking through occasionally

patch set 8:
  looks good in PDF previewers, consistent thickness of stems in print,  
consistent thickness of staff lines in print, single pixels/edges sticking  
through more often both in print as well as preview.  Ridiculously large  
file size increase in PDF (we are talking about something akin to doubling).

patch set 7:
  looks good in PDF previewers, mostly consistent thickness of stems in  
print (occasionally one pixel off), no pixels/edges sticking through in  
print but occasionally in previews.  File size like patch set 8.

Both patch set 7 and patch set 8 are identical for direct PNG
production: the output is comparable to PDF previewers but less sharp,
single (sub-)pixels with a tendency to stick through in exchange for
consistent line width.

Compared to current state, line thicknesses are more consistent
(meaning that lines look a bit blurry, without intermittent sharp and
rare over-thick lines as they appear currently).

PostScript file size is pretty much identical.


Drawing primitives of PostScript and PDF are different: PostScript can draw  
arcs, PDF can draw Bezier shapes.  Both can _stroke_ with a circular pen,  
but stems require multiple strokes on the same area and that is  
incompatible with good-looking Porter/Duff antialiasing at nominal drawing  
resolution which is apparently what Cairo does (used by Evince).


All those are pretty untasty compromises.  Here are several improvements:

a) make sure that important thicknesses are a multiple of 1/300 dpi, or  
0.24bp ("big points", PostScript points, 1/72 in).  That way, they will get  
rendered with the same number of pixels every time for devices offering  
multiples of 300dpi, without the need for setting strokeadjust.

b) write PDF directly and use Bezier splines for rounding off corners  
instead of quartercircles.  Keep writing PostScript as we do.  This leads  
to a difference in rendering via PDF and PostScript.  Converting from one  
to the other will still explode file sizes.

c) create ad-hoc fonts containing stems.  That allows us to do hinting for  
the resolution-fixing stuff and work consistently with Bezier corners  
(fonts in both PostScript and PDF are comparable, while the graphical  
drawing primitives aren't).  Rendering should improve (actually also in the  
PostScript/PNG case), and PDF file sizes would remain civil.  Since  
previewers and other renderers invest a lot more energy into getting  
characters to render nicely/correctly, chances are that we'll hit fewer  
bugs and inconsistencies.

d) allow the user to express "rendering intent" (for option --png, we  
already have one intent) and strip the PostScript of those constructs where  
we know that they are irrelevant for the given intent.  High-resolution PDF  
for the sake of printing can be done in the old way (though preferably  
without setting strokeadjustment) and will then have reasonable size.  It  
just will look like crap when previewing.  Which is basically what this  
issue is about.

In short: apart from the work-intensive options b) and c), what we have  
available is compromises.

I'd lean towards Patch set 7 for now.  We'll get complaints about  
ridiculous size increases in PDF files, and possibly about slightly less  
consistent thicknesses for staff lines in print.  Which could be addressed  
eventually by trying to put option a) to work.  Since staff line thickness  
is the base for several other thicknesses, we'd get more consistency  
elsewhere as well.  And of course, the improvements vanish again when the  
output device does not offer a multiple of 300dpi resolution.

While this does not offer a relevant improvement in print, the improvement  
in previewers would be significant.  Actually to the degree that I can  
imagine people greatly preferring the output of pdftocairo over the direct  
Ghostscript output for screen view since sharp lines make for better  
readability than accurate subpixel positioning via gray levels.  And let's  
face it: people _do_ use 100dpi output for more than finding out how the  
printed version would look in case you lost your contact lenses.


--
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