Re: Be serious about setstrokeadjust in PostScript primitives (issue 8663044)

[David Kastrup]

"Keith OHara" <address@hidden> writes:

> On Thu, 25 Apr 2013 09:39:23 -0700, <address@hidden> wrote:
>
>> On 2013/04/25 07:47:47, dak wrote:
>>
>> Which is mostly a problem of the previewers (_they_ are supposed to
>> approximate the output of the PDF) but it still affects our users and
>> we get the blame for it because "it works for others" (TM)
>
> The "others" may well have assigned a junior programmer to keep trying
> things until things looked reasonable on his previewer. I would not
> think the beam shown at
> <http://lilypond.org/web/about/automated-engraving/software> would
> escape complaints long enough to make it into a release, but it did.

Hey, I can remember somebody proposing to use parallel strokes for
producing a rounded rectangle...

>> But another problem is that of beams and stems not blending perfectly.
>> We won't get rid of that before the release.  It requires typesetting
>> beams _along_ with their stems.  It's not new, either.
>
> The code tries to use parameters like 'blot-diameter' to fit the beam
> to the stem.  I am not sure if the code allows for varying
> blot-diameter' all details (such as the joint between stem and
> note-head) but the attempt has been begun.

I am not saying that the code doesn't _try_ to fit the beam to the stem.
At infinite resolution it will succeed.  But it doesn't when we have to
take rasterization into account, in particular stroke adjustment.

> Having the pretty-preview option increase 'blot-diameter' to the width
> of the thicker of the stem or single-bar-line, along with an ugly
> comment including a reminder to "synchronize with Stem.thickness",
> seems the simplest way to simplify the output for the sake of
> low-quality renderers, and to be easily reversible.

I have no idea what you are talking about.  Geometrically, stems and
beams and barlines _are_ fitting properly.  But different rasterization
choices break this equivalence in different ways.  That's why I decided
to leave the strokeadjust value at its default.  For PDF and high
resolution, we get no stroke adjustment and thus lines that can be
[+0,+1) pixels off at each side independently rather than [-0.75,+0.75]
at each side with a complex joint distribution.

This leaves us with no corner/border artifacts.  In contrast, for low
resolution bitmap rendering directly from PostScript we get stroke
adjustment but artifacts.

It's conceivable to change filled outlines back to using the default
strokeadjustment rather than switching strokeadjustment off.  While
strokeadjustment does not make sense for filled shapes regarding the
thickness, the resulting somewhat more randomized distribution of the
outlines at least has a better chance not to stick through stroke
adjusted stems because of its smaller mean.

-- 
David Kastrup