[Octave-bug-tracker] [bug #45494] Patches have spurious (antialising) lines in vector printout

[Dan Sebald]

Follow-up Comment #27, bug #45494 (project octave):

>> I also though about that but think about 3D crossing patches: 

What is the issue there?  That blue is blending with red when it shouldn't?  I
know that gnuplot has an issue with the intersecting surface, but that is
because no one (probably me) has gotten around to a true surface depth sorting
algorithm, but instead uses the approximating painter's algorithm.

>> I also though about that but one of the points of splitting polygons into
triangles is to handle color gradients. In this case it is unlikely that 2
neighbor triangles have the same color and there is nothing to pack back.

Now that I comprehend the issue, it seems that gnuplot should have the same
problem with PDF output.  And it does, but in a less obvious way.  If I remove
the black mesh covering the edges:


set(grandkids, 'linestyle', 'none')


('grandkids' is the surface object), then viewing the gnuplot output in
Acroread results in the same issue with "Smooth line art" on/off.

Note that smoothing lines is a nice thing to have on the edges, where one
intends it to be.  Otherwise that outer edge of the sombrero looks kind of
block-y.

>> PS: The relevant bug report for Inkscape is [1]. I know it looks like
off-topic but the discussion there is quite instructive. [1]
https://bugs.launchpad.net/inkscape/+bug/170356

Yes, and it is a twelve year bug because the developers (a few comments within
that thread) realize how difficult a problem they would have to address it. 
Once the horse is out of the barn regarding the structure of that tessellated
surface, it's difficult to address the issue.

This is a very general problem with PDF (or, I would say any vector-based
format...in SVG we are forcing crisp edges by the hint).  Here's a complaint
from an unhappy camper on the Adobe site:

Feb 18, 2012 5:00 AM
Frame artifacts appearing in PDF output
https://forums.adobe.com/thread/964508

In which black lines appear rather than white (simply because of the
foreground/background choice).  The term "stitching" is bandied about, sort of
a euphemistic way of discounting the problem by giving it a "well-known" name.
 I'd actually prefer the more Cohen-eque "cracking", in the sense "that's how
the light gets in".

Here again from Adobe is a reference to the issue in one of their products:

Thin white, dark lines (stitching) | Export to PDF | InDesign CS2 and later
https://helpx.adobe.com/indesign/kb/thin-white-dark-lines-stitching.html

Some convoluted methodology for dealing with this, the crux of which seems to
be "turn off 'Smooth line art'".

I would think that as an alternative to smoothing lines of all individual
objects, the PDF viewer could first render the whole scene to the desired
output resolution, and then apply image smoothing.  But I suppose the
philosophical issue is that vector-based descriptions are scalable.

I think the best that can be done as far as gl2ps is to somehow patch those
individual tessellation triangles for a mesh square (or patch) back together. 
Apparently Octave isn't alone in the individual triangles:

https://www.mathworks.com/matlabcentral/answers/15388-artifacts-in-figures-exported-as-pdf-from-matlab

Again, an unhappy camper, who concludes Adobe isn't at fault.  But in some
sense it is a problem with the PDF language, or any vector-based description. 
In the grand scheme of computer graphics, it seems there should be a way of
describing in the language a "tessellated surface" so that the PDF-viewer
knows how to deal with smoothing at edges.  A tessellated surface would
probably be something described more as a mesh than individual triangles in
order to avoid any type of NP-problem of putting tessellations back together.

The most productive effort in the long run would be if the graphics community
were to hassle Adobe to extend their PDF/PS definition to include tessellated
surfaces.  (I'm not 100% sure such a thing doesn't already exist in the latest
definition, but digging into PostScript requires all the documents, which I no
longer have access to.)  That would then make life easier for all the viewers,
etc. that need to process PostScript.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45494>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/