(In reply to comment #0)

> The attached file displays a thin line when called directly with Ghostscript
> and screen display.
> 
> After either ps2ps or ps2pdf, the thin line loses stroke adjustment of the
> clip path and is displayed thick when calling Ghostscript on the resulting
> file.

To me the line looks the same when rendering the PostScript file, the Ghostscript-converted PDF file and the Acrobat Distiller converted PDF file.

Rather than discussing what's on your screen versus mine, I think it would be best if you give me a command line, outputting to file, so that we can have an objective output to look at (and count pixels if need be).


> That's bad as we use ps2pdf for generating PDF files in LilyPond, and it
> means that the PDF becomes unsuitable for low-resolution devices like screen
> viewers.

There is no 'strokepath' operator in PDF so, like Acrobat Distiller, we output an absolute path. You are emitting the same path twice, once with stroke adjust and once without, this causes us to emit 2 slightly different paths.

At the moment I don;t see a problem. This is realistically the best that can be done in PDF to mimic a PostScript feature that is not present in PDF (strokepath). However, I do see some slight differences in the way that Distiller treats this compared to the way we do. I don't think they are a problem, but I'm prepared to look further.

I'm not sure why you are using this construction, I'm assuming its a simplified example of the real usage, its not a great way to use PostScript, and its not obvious to me from the simplified file what you are trying to achieve. If you could  explain why you are doing this it might help understand your problem.

Note stems and several other constructs in LilyPond are basically rectangles with rounded corners.  The rectangles are small enough to require stroke adjustment.

After checking the PDF specs I agree that a stroke adjusted clipping path is not achievable: applying stroke adjustment when converting from PostScript to PDF, however, does not make actual sense since the target resolution at which the PDF is going to be rendered is unknown.

So now the rendering order is done the other way round: first draw the outline as a rounded rectangle and use it as clip region, then draw a stroke adjusted rectangular line inside.

This particular problem report can be considered invalid (apart from it not making sense to apply stroke adjustment at all when converting to PDF as the target resolution is unknown).

In the context of trying to write a test file, however, a number of deficiencies in path conversion already affecting PostScript interpretation have cropped up.  The example file used shows a number of deficiencies and has been posted to the developer list.  Sorting the symptoms into isolated bugs will hopefully happen there.

As for the used command line options: none, the output was to graphical display.  That might render it dependent on the output device and/or its resolution.  If more information is needed in that regard, please ask back.

(In reply to comment #2)
> Note stems and several other constructs in LilyPond are basically rectangles
> with rounded corners.  The rectangles are small enough to require stroke
> adjustment.

At low resolution, presumably. 


> After checking the PDF specs I agree that a stroke adjusted clipping path is
> not achievable: applying stroke adjustment when converting from PostScript
> to PDF, however, does not make actual sense since the target resolution at
> which the PDF is going to be rendered is unknown.

That is true, but automatic stroke adjustment is still present in PDF, and still does make sense as the rendering engine knows, at the time of rendering, what the effective resolution is and is able to apply stroke adjustment.

So *strokes* can still be adjusted, clip paths which are the result of strokepath can't. But I don't understand why you would want to do:

true setstrokeadjust
<path>
clip
false setstrokeadjust
<same path>
stroke

instead of 

true setstrokeadjust
<path>
stroke

The two are equivalent as far as I can see, but the latter will (or should) be preserved in PDF, while the former cannot be, due to the fact that strokepath isn't part of PDF.


> This particular problem report can be considered invalid (apart from it not
> making sense to apply stroke adjustment at all when converting to PDF as the
> target resolution is unknown).

As I said, setting automatic stroke adjustment is still possible, and does make sense for PDF.


> have cropped up.  The example file used shows a number of deficiencies and
> has been posted to the developer list.  Sorting the symptoms into isolated
> bugs will hopefully happen there.

If you think there are problems with paths, please open a bug report (or reports). The developer list is not the correct place to discuss bugs.

 
> As for the used command line options: none, the output was to graphical
> display.  That might render it dependent on the output device and/or its
> resolution.  If more information is needed in that regard, please ask back.

The reason for asking for a command line which rendered to a file was so that we could look at an objective result, rather than a subjective display device. Armed with specific parameters we should have got the same output, which makes it much easier to compare than talking about 'thin' lines and such.

However, you seem happy that this bug is resolved, so I'll close it.

There are several misunderstandings here.  I am aware that PDF offers stroke adjustment for strokes.  But that does not mean that it makes sense for ps2pdf to ever _apply_ strokeadjustment, like it does with its path rendition of strokepath.  Instead it just needs to _record_ the value of strokeadjustment used (if strokepath is used as a clip path, there is no use for the recorded value, unfortunately, unless one figures out some magic using "transparency" for rendering, but that's unlikely to be desirable).

There are _three_ different values of strokeadjustment warranting recording: true, false, and default.  Since ps2pdf can't know the default of the PDF rendering device, it needs to know whether it sets SA in the ExtGState explicitly to false or true or not at all.

With regard to using the same path as clippath and for rendering a stroke: of course.  This was just for the sake of the bug report.  In the real situation, namely needing to produce slim rectangles with rounded corners (but not just circular butts), there are two shapes to be combined:

One is the non-strokeadjusted full shape, a rectangle with rounded corners, the other is a strokeadjusted rectangular stroke bleeding across the rounded corners.

You get either rounded corners, or strokeadjustment for the (extended) spine.  You can't have both.  So one of those shapes gets to be the clip area for the other shape, and the combination of both is the complete result.  Somewhat deficient as the round corner placement does not take the stroke adjustment of the spine into account and so up to a pixel of the rounding curve might get cut off.

But even discounting stroke adjustment, we need to do this shape with a filled area rather than a stroke, since at low resolutions, the curvature radius is much less than a pixel, and so _stroking_ the outline with a linewidth close to zero (corresponding to the corner diameter) would add half a pixel of excess at each side even before the act of rasterization adds additional excess.

On screen, you usually expect to see a one or two-pixel line, not some ridiculously fattened stroke.  In high resolution, it is an almost but not quite rectangular shape.  Matching that to the limited rendering model is not easy.

(In reply to comment #4)
> There are several misunderstandings here.  I am aware that PDF offers stroke
> adjustment for strokes.  But that does not mean that it makes sense for
> ps2pdf to ever _apply_ strokeadjustment, like it does with its path
> rendition of strokepath.

The difference in the paths is negligible at the default resolution of the pdfwrite device.

In order for the interpreter to *not* apply setstrokeadjust to the path returned by strokepath it would require the interpreter to have knowledge of the device, which in general it does not. The path resulting from strokepath is constructed and returned by the PostScript interpreter without any reference to the device at all, simply by following the usual rules of the language.

Obviously we could do something about that, but strokepath is a rarely used operator in general PostScript, and as I said, at the default resolution of the device it makes negligible difference anyway.

I'm still willing to be persuaded, but so far you haven't provided me with any evidence that I need to address this as a problem.


>  Instead it just needs to _record_ the value of
> strokeadjustment

Like the other graphics state parameters, this is indeed recorded, though whether it is emitted depends on a number of factors. We try not to emit parameters that aren't used.


> On screen, you usually expect to see a one or two-pixel line, not some
> ridiculously fattened stroke.  In high resolution, it is an almost but not
> quite rectangular shape.  Matching that to the limited rendering model is
> not easy.

Like your post to gs-devel, much of this seems to have little or nothing to do with pdfwrite. The Ghostscript rendering engine isn't my area, so I'd suggest you open bugs for the perceived problems and you can discuss this with better qualified developers.