Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2691 > unrolled thread

linecap rendering with zero-length lines

Back to article view | Back to comp.lang.postscript

Contents

  linecap rendering with zero-length lines Alan <alan.isaac@gmail.com> - 2016-07-12 07:47 -0700
    Re: linecap rendering with zero-length lines ken <ken@spamcop.net> - 2016-07-12 17:12 +0100
      Re: linecap rendering with zero-length lines Alan <alan.isaac@gmail.com> - 2016-07-12 10:37 -0700
        Re: linecap rendering with zero-length lines Alan <alan.isaac@gmail.com> - 2016-07-12 10:58 -0700
          Re: linecap rendering with zero-length lines Markus Triska <triska@metalevel.at> - 2016-07-12 21:39 +0200
        Re: linecap rendering with zero-length lines ken <ken@spamcop.net> - 2016-07-13 07:47 +0100
          Re: linecap rendering with zero-length lines Peter Billam <peter@www.pjb.com.au> - 2016-07-20 01:09 +0000
    Re: linecap rendering with zero-length lines jdaw1 <jdawiseman@gmail.com> - 2016-07-28 03:02 -0700

#2691 — linecap rendering with zero-length lines

A GhostScript bug report (not mine) was rejected as invalid that appears valid to me: http://bugs.ghostscript.com/show_bug.cgi?id=695830 

As I read p.672 of PLRM3, the bug reporter was correct that the cap should be rendered.

In fact, GhostScript previously accepted and corrected a bug report on the rounded cap, and it does render for zero-length lines.  So now there is an inconsistency in the handling of the two line caps.

Am I right that this is a GhostScript bug?

Admittedly, Distiller behaves the same way.

[toc] | [next] | [standalone]

#2692

In article <a40375f0-4eed-4d43-aa23-4f005124400f@googlegroups.com>, 
alan.isaac@gmail.com says...

 
> A GhostScript bug report (not mine) was rejected as invalid that appears valid to me: http://bugs.ghostscript.com/show_bug.cgi?id=695830 

Something very odd here, after I closed your bug report as invalid 

http://bugs.ghostscript.com/show_bug.cgi?id=696920

you then appear to have moved the conversation onto a different bug, 
695830, which had previously been closed for the same reason. Was this 
intentional ? I admit both of us commenting on the bug 696920 missed the 
fact that you had jumped to a different bug report.


> Admittedly, Distiller behaves the same way.

As do 2 other PostScript RIPs, including I believe the Adobe  CPSI RIP 
which, as I noted in the bug report, we take to be the reference 
implementation.

[toc] | [prev] | [next] | [standalone]

#2693

I found the other bug after making my report.  I then realized I should have opened the discussion here, which I have now done.  Apologies for the backwards timeline.

Putting aside the idea of that a reference RIP should serve as a standard even if it violates the written reference manual, can you offer any conceptual rationalization for the inconsistent treatment of the round and square line caps?

Thanks!

[toc] | [prev] | [next] | [standalone]

#2694

The explanation is rather obvious but occurs in the PDF manual:
"If a subpath is degenerate (consists of a single-point closed path or of two or more points at the same coordinates), the S operator shall paint it only if round line caps have been specified, producing a filled circle centered at the single point. If butt or projecting square line caps have been specified, S shall produce no output, because the orientation of the caps would be indeterminate."

[toc] | [prev] | [next] | [standalone]

#2695

Alan <alan.isaac@gmail.com> writes:

> The explanation is rather obvious but occurs in the PDF manual:

Thank you Alan for sorting this out! It's a compelling argument.

All the best,
Markus

[toc] | [prev] | [next] | [standalone]

#2696

In article <f6ca5c7c-a9d9-40af-a5a2-8b1faf54a826@googlegroups.com>, 
alan.isaac@gmail.com says...

> Putting aside the idea of that a reference RIP should serve as a 
standard even if it violates the written reference manual, can you offer 
any conceptual rationalization for the inconsistent treatment of the 
round and square line caps?

No, I haven't tried to.

In fact Ghostscript used to draw no caps at all on zero length strokes, 
which I see as an entirely defensible position; you aren't drawing the 
stroke, so why draw the caps.

The comments in our code suggest that (some considerable time ago) it 
was pointed out that Adobe RIPs in fact draw circles for round caps. The 
comments indicate that the initial response was to alter the code to 
draw all line caps; which I would see as the other defensible position.

However further testing indicated that projecting square line caps are 
not drawn (apparently at least some versions of Acrobat did draw 
extremely thin lines for butt end caps, but this seems to be no longer 
the case).

Nevertheless, our customers expect that a file printed via Ghostscript 
should match one printed via Adobe. Standard industry test suites, such 
as the Quality Logic tests, use Adobe RIPs as the reference and require 
that interpreters match that behavior; ant deviations have to be 
explained, even when its things like architectural limits being 
different.

As a result Ghostscript was modified to follow the reference 
implementation.

[toc] | [prev] | [next] | [standalone]

#2708

On 2016-07-13, ken <ken@spamcop.net> wrote:
> Ghostscript used to draw no caps at all on zero length strokes, 
> which I see as an entirely defensible position;
> you aren't drawing the stroke, so why draw the caps.

By a strange coincidence, I yesterday ran into a use-case that
justifies that position... I've been playing with  ctransform
from chapter 8 of
  http://www.math.ubc.ca/~cass/graphics/manual/
to implement some fun transforms. One of them was a "collapse"
transform (think Black Hole, or Macular Degeneration) in which
everything within a given circle collapses down to the center, and
everything outside that circle stretches inward to fill the gap.
This means that all the points inside the circle become at zero
length from other.  I want them to vanish, to not be displayed.
I don't want them to display their caps.

> As a result Ghostscript was modified to follow the reference 
> implementation.

Hard to argue against that, though; Adobe wrote the book...

Regards,  Peter

-- 

Peter Billam    www.pjb.com.au    www.pjb.com.au/comp/contact.html

[toc] | [prev] | [next] | [standalone]

#2710

Related bug, recently discussed, about Adobe trimming moveto’s:
http://groups.google.com/forum/#!topic/comp.lang.postscript/amUp28S-JFM

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web