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

[dak]

On 2013/04/25 07:47:47, dak wrote:
> On 2013/04/25 03:10:59, Keith wrote:
> > LGTM,
> > if you really think masking the stem is a reliable solution.

> AAAAahhahhahahahahahahahaha.

> Of course I really don't think it a reliable solution.  I mean, look
> at how ridiculous the code is: I am bending the mask away from the
> stroke wherever possible exactly because the set of previewers and
> renderers we are trying to placate is trying to sabotage the rendering
> in any imaginable and unimaginable way.

> The code is a piece of crock based on the principle "Anything that can
> go wrong, will.  And then more.", and that's exactly what the
> previewers are doing here.

To give this some perspective: the starting point for this issue, an
issue about which at least Janek feels strongly enough to repeatedly
raise a stink because somebody (TM) should be doing something (TM)
about it, was that our output looks bad in PDF previewers.

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

We are going through Ghostscript (which is a problem in itself) for
producing our graphics and producing our PDF.

I don't see that we will be able to change this before 2.18.  For
better or worse, the current set of previewers and the current version
of LilyPond, once it is declared stable, will be the official face of
LilyPond for about a year at least.

The current proposal is not a "reliable solution".  It is a balancing
of unsavory compromises which should not have been necessary in the
first place.

Probably the worst offense of this approach is the combination of a
full outline as clip area with a stroke adjusted rectangle in the
middle.  The stroke adjustment removes thickness from the side of the
stroke which means that the remaining stroke hits the curve in the
clip area not tangentially (which would be correct) but at an angle.

The right way would be to move the curve along with the stroke
adjustment.  We can't do that when generating PDF, but when generating
PDF, the current choice of settings switches off stroke adjustment.

We _don't_ do it yet when creating bitmaps.  When creating bitmaps,
the whole stroke adjustment mechanism could be done manually, and then
it would allow moving the curvature and making it symmetrical.

This is something still possible to play with in the gear-up for
release if we want to.

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.  If we would
discretize a few dimensions a priori, they'd render reproducibly.


https://codereview.appspot.com/8663044/