Be serious about setstrokeadjust in PostScript primitives

Be serious about setstrokeadjust in PostScript primitives

This particularly concerns draw_round_box which is used for drawing
lines with a rounded ending.  If the width/height ratio or its inverse
exceeds 2, the box is considered to be a "line".  In this case, first
a clipping path is established representing the whole shape and
extended widely in the area of the "main stroke".  The reason for this
extension is to avoid both clip area and stroke competing for the
outline.  While this is not a problem for the PostScript or PDF
rendering model, the Cairo bitmap rendering library employs
Porter-Duff compositing for antialiasing amounting to "cheap man's
antialiasing" not requiring a higher rendering resolution but relying
on edges affecting a single pixel to be independent.

Porter-Duff requires us not to have multiple parallel strokes or clip
areas if we want to avoid wrong sub-pixel grayness levels (and
consequently lines appearing too thick or thin) in Cairo-based
previewers like Evince.

After establishing the clip area, a stroke is drawn through.  This
stroke may (at the PostScript device's discretion) employ
strokeadjustment further correcting the apparent thickness.
Ghostscript employs stroke adjustment when rendering at a resolution
below 150dpi.  Stroke adjustment does not pass into PDF, however, when
ps2pdf runs.

Ghostscript performs sub-pixel rendering for antialiasing which
reduces the amount of discontinuities possibly caused by joining
stroke-adjusted shapes with full shapes.

It turns out that sharper contours can be achieved by using strokepath
and fill instead of a plain stroke.  However, the resulting crisper
stems tend to combine worse with beams, so this approach has not been
pursued.


Also contains commits

    Don't meddle with Ghostscript's choice of currentstrokeadjust
    
    It should be appropriate for device and resolution by default.


    Make stroke_and_fill? PostScript operator that fills conditionally


    Make music-drawing-routines.ps require PostScript 2.0
    
    There is no point having conditional code around setstrokeadjust and
    its ilk any more.

[janek, 2013-04-12 11:06:30]

David,
it's great to see you working on this!
However, as you can see in tracker issue, this patch doesn't solve the problem. 
If you'd nevertheless like me to analyze this patchset, let me know.  I'm very
interested in seeing this issue solved!

best,
Janek

[dak, 2013-04-12 14:57:07]

Fix problem with path initialization, use same drawing method for staff lines

[janek, 2013-04-14 20:38:12]

David,

i'm sorry, but i don't understand what the code does.  Obviously, it would help
if i knew Postscript ;) but unfortunately i don't have time to learn it now. 
Since i suppose that quite a few devs may be in a similar situation, i think
that adding some comments would be a good idea, even if they were completely
obvious for people knowing PostScript.

By the way: do i understand correctly that a rounded rectangle is created as two
objects - a "sharp" rectangle and a "rounded" line around it?

best,
Janek

[dak, 2013-04-14 21:17:33]

On 2013/04/14 20:38:12, janek wrote:
> David,
> 
> i'm sorry, but i don't understand what the code does.  Obviously, it would
help
> if i knew Postscript ;) but unfortunately i don't have time to learn it now. 

The most important resource is PLRM.pdf (available on Adobe's website,
though the location changes).

> Since i suppose that quite a few devs may be in a similar situation, i think
> that adding some comments would be a good idea, even if they were completely
> obvious for people knowing PostScript.

There is a reason this file is commented sparingly: it appears in
every PostScript file produced by LilyPond.

PostScript is a rather idiosyncratic language, so one can't really
replace knowing the language with liberal amounts of commenting.

> By the way: do i understand correctly that a rounded rectangle is
> created as two objects - a "sharp" rectangle and a "rounded" line
> around it?

There is no such things as a "rounded" line, but the corner join style
might be producing circles.

At any rate, this kind of rendition is only used when all of width,
height, and corner diameter are non-zero.  And calling painting
operations "objects" is a somewhat strange view.

[janek, 2013-04-14 21:43:36]

2013/4/14  <dak@gnu.org>:
> On 2013/04/14 20:38:12, janek wrote:
>> i'm sorry, but i don't understand what the code does.
>> Obviously, it would help if i knew Postscript ;) but
>> unfortunately i don't have time to learn it now.
>
> The most important resource is PLRM.pdf (available on Adobe's website,
> though the location changes).

Yeah, i've downloaded it.  900 pages... you may have to wait a bit for
my review.... (not that i'm going to read it whole, but anyway its a
lot of material and i'm *really* busy (don't be surprised if i
disappear from the lists for a couple of days)

>> Since i suppose that quite a few devs may be in a similar situation, i
>> think that adding some comments would be a good idea,
>> even if they were completely
>> obvious for people knowing PostScript.
>
> There is a reason this file is commented sparingly: it appears in
> every PostScript file produced by LilyPond.

Hmm.
Does it appear in pdfs too?

> PostScript is a rather idiosyncratic language, so one can't really
> replace knowing the language with liberal amounts of commenting.

Too bad.
So, just from the description: i understand that there's some sort of
strokeadjusted border drawn around the actual rectangle (i'm referring
to the thing you called "clipping path").  This strikes me as
suspicious: how are we to fit 3 "layers" (strokes or whatever) into
something that renders at about 1 pixel width?  I mean, when we have a
stem (rounded rectangle), its usually ~1px on screen, and in that 1
pixel we squeze strokeadjusted left edge, the rectangle, and the
strokeadjusted right edge?  Isn't that too much, and isn't this what's
causing this "disappearing lines" effect in poppler?

>> By the way: do i understand correctly that a rounded rectangle is
>> created as two objects - a "sharp" rectangle and a "rounded" line
>> around it?
>
> There is no such things as a "rounded" line, but the corner join style
> might be producing circles.

That's what i meant by the "rounded line".  Obviously you know the
terminology better :)

> At any rate, this kind of rendition is only used when all of width,
> height, and corner diameter are non-zero.  And calling painting
> operations "objects" is a somewhat strange view.

See the second sentence above.
Anyway, thanks for explanation.

Janek

[dak, 2013-04-14 22:43:07]

On 2013/04/14 21:43:36, janek wrote:
> 2013/4/14  <dak@gnu.org>:
> > On 2013/04/14 20:38:12, janek wrote:
> >> i'm sorry, but i don't understand what the code does.
> >> Obviously, it would help if i knew Postscript ;) but
> >> unfortunately i don't have time to learn it now.
> >
> > The most important resource is PLRM.pdf (available on Adobe's website,
> > though the location changes).
> 
> Yeah, i've downloaded it.  900 pages...

It's astonishing how much worse pretty much every other resource is.
Basically, whenever you find something unclear from reading the PLRM,
a web search or any other book will not help, either.

[dak, 2013-04-16 13:42:58]

"Minimally invasive" version.  Just use strokes and stroke adjustment when
called for.

[dak, 2013-04-16 16:12:15]

Define and use non_aliased_stroke to have Ghostscript render lines in PNG nicer

[dak, 2013-04-18 19:53:41]

Don't mess with Ghostscript's choice of currentstrokeadjust

[dak, 2013-04-18 20:39:18]

Fix linecaps on stems

[dak, 2013-04-21 15:59:15]

Remove strokepath-based stroking, change clip shape to accommodate for
Porter-Duff

[dak, 2013-04-21 23:17:59]

reenable unconditional stroke adjustment

[dak, 2013-04-23 15:03:30]

Revert to default strokeadjust, add -dno-pretty-previews-option, document it

[Keith, 2013-04-23 21:56:07]

Confirming that the .pdf size doubles, but only if we measure relative to the
size of the smaller .pdfs we get if we know to use -dno-point-and-click.  The
time required to process the larger .ps was less that 1% the total time to
compile my test .ly files.

Confirming that the resulting larger .pdf has better and more consistent line
thickness when previewed with Adobe Reader on WinXP.

I had to look for a while to find a PDF previewer that showed the original
problem.  Maybe no-pretty-previews by default?

The Evince shipped with Gnome as DocumentViewer 2.32.0
using poppler/cairo (0.14.4) shows no problem (good previews with visually
consistent line thicknesses at all zoom).  SumatraPDF, using the MuPDF engine,
shows no problem.  AcroRead on WinXP shows a minor problem, that only becomes
obvious I we turn on the setting "Enhance Thin Lines".  (I just did a fresh
install of Adobe Reader XI and found "EnhanceThinLines" is set by default.)
Once I found the problem, this patch did fix it.

[dak, 2013-04-23 22:22:53]

On 2013/04/23 21:56:07, Keith wrote:
> Confirming that the .pdf size doubles, but only if we measure relative to the
> size of the smaller .pdfs we get if we know to use -dno-point-and-click.  The
> time required to process the larger .ps was less that 1% the total time to
> compile my test .ly files.
> 
> Confirming that the resulting larger .pdf has better and more consistent line
> thickness when previewed with Adobe Reader on WinXP.
> 
> I had to look for a while to find a PDF previewer that showed the original
> problem.  Maybe no-pretty-previews by default?
> 
> The Evince shipped with Gnome as DocumentViewer 2.32.0
> using poppler/cairo (0.14.4) shows no problem (good previews with visually
> consistent line thicknesses at all zoom).  SumatraPDF, using the MuPDF engine,
> shows no problem.  AcroRead on WinXP shows a minor problem, that only becomes
> obvious I we turn on the setting "Enhance Thin Lines".  (I just did a fresh
> install of Adobe Reader XI and found "EnhanceThinLines" is set by default.)
> Once I found the problem, this patch did fix it.

Evince in Raring Ringtail (upcoming Ubuntu) is
GNOME Document Viewer 3.6.1
and definitely shows the problem.  Libraries are
ii  libcairo2:i386 1.12.14-0ubu i386         The Cairo 2D vector graphics libr
ri  libpoppler28:i 0.20.5-1ubun i386         PDF rendering library

xpdf (from several versions back, the last one that does not just segfault) too.

[Keith, 2013-04-25 03:10:59]

LGTM,
if you really think masking the stem is a reliable solution.


On 2013/04/23 22:22:53, dak wrote:
> Evince in Raring Ringtail (upcoming Ubuntu) is
> GNOME Document Viewer 3.6.1
> and definitely shows the problem. 

I have never been able to figure out how to update Evince; now I am happy to
have failed.
GSView always shows uniform stem thickness, and GNU GV always looks bad, with or
without this patch.  With XPDF 3.03 I can finally see the problem on Linux, and
of course this patch fixes it.

https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.ps
File ps/music-drawing-routines.ps (right):

https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.p...
ps/music-drawing-routines.ps:107: abs exch abs exch
If you still have reliable notes on the stack layout, a comment or two would be
very nice, especially here as we go into the nested ifs.

[dak, 2013-04-25 07:47:47]

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.

I can totally and seriously improve the output for bitmap rendering
from Ghostscript: in case we are doing _bitmaps_, I can do all sort of
quantization tricks because then the device coordinate space is known.
So far, the code does not make any use of device coordinates.

And GSView would likely be able to use this sort of code.  For PDF,
this route is barred.

> https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.ps
> File ps/music-drawing-routines.ps (right):
> 
>
https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.p...
> ps/music-drawing-routines.ps:107: abs exch abs exch
> If you still have reliable notes on the stack layout, a comment or two would
be
> very nice, especially here as we go into the nested ifs.

The stack layout is pretty much trivial throughout.  At the beginning,
width and height are made non-negative, the coordinate system is reset
to make the inner box (sans linewidth) start at coordinates 0 0, and
the stack layout is

savedmatrix width height

pretty much everywhere.  The blot diameter is put into
currentlinewidth pretty much at the start.

Suggestions for a good comment?

[dak, 2013-04-25 16:39:23]

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.

[dak, 2013-04-25 20:19:37]

"Keith OHara" <k-ohara5a5a@oco.net> writes:

> On Thu, 25 Apr 2013 09:39:23 -0700, <dak@gnu.org> 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

[janek, 2013-04-27 20:40:31]

2013/4/25  <dak@gnu.org>:
> 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,

It was not my intention to demand that somebody is must do something.
If it looked like this, i apologize.
I hadn't known that the issue would be so complicated to fix.  Anyway,
i appreciate your efforts a lot, David.

As i see it, we cannot get anything better than a compromise for 2.18.
 From what i see, the compromise that David suggests seems to be a
reasonable one, even if the code is - in a way - unreliable.

Janek

[dak, 2013-11-30 18:14:21]

Route everything through strokeadjust, add -dstrokeadjust option, off by default

[janek, 2013-11-30 22:11:43]

LGTM as per tracker comment (the results, haven't read the code yet...)

Janek