lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 2658 in lilypond: wrong stem rendering (incons


From: lilypond
Subject: Re: [Lilypond-auto] Issue 2658 in lilypond: wrong stem rendering (inconsistent thickness)
Date: Mon, 22 Apr 2013 13:09:31 +0000


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

Regarding comment #69: I am oscillating in my opinion. Pixels sticking out is bad. But a +20% variation in thickness in print is also bad. I've tried devising a scheme where beams can be strokeadjusted just at the right and left edge with stem stickness in mind, but making this work with the various imaging models is just not feasible.

Now we had stroke adjustment on unconditionally before, and it made staff line thickness consistent. Why is the output now worse elsewhere for print? Because of the way things were drawn, stems turned out somewhat too thick on average, still with some variation, but at least covering their outline fully and then some. That prevented things like beams sticking through but lead to the ungainly variations in thickness of the stems and much too thick stems in previewers with the Cairo rendering approach.

So currently I am leaning backwards to let stroke adjustment revert to the default, leaving us with a variation in print line thickness. Possibly with an option for overriding.

How can we improve over that state? By discretizing our placements and thicknesses. If line thicknesses are (say) a multiple of 1/150 dpi and are positioned at multiples of 1/150 dpi, we don't need no stinking stroke adjustment. Every item will render looking identical and things will line up properly.

If we do all of our positioning _ignoring_ an underlying grid, we will always have to compromise between accurate positioning and accurate thickness, and if various items are positioned independently on a not-supported-by-reality grid, the compromises will show.

Now how to arrive at reality? 1/300 inch is 0.24pt in PostScript parlance. We are currently working with a 0.4 pt base which are 1/180 in. That does not map fabulously to current printers (well, Epson ink printers maybe). So perhaps we need to fatten up to 0.48pt as our metric. It's not like we don't already get to see this thickness in rasterization...

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]