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

[Dan Sebald]

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

> > Then I suppose you did not read comment #14 which clearly states that
setting anti-aliasing off in the viewer will remove those lines.

OK, so anti-aliasing in the case of PDF doesn't refer to smoothing the whole
composite image.  Instead, it refers to individual objects and line art. 
Because of smoothing applied to the edges of all the individual tessellation
triangles, the anti-aliasing feature now creates the "cracks".  Adobe Acrobat
has the same behavior but in its settings is

"Smooth line art"
"Smooth images"
"Enhance thin lines"

the latter probably just being a widening of low line-width numbers so that
they don't disappear from view.

For Inkscape, I've changed the setting inside the SVG file for
'shape-rendering' and at the same time modified some of the Rendering settings
in the Inkscape viewer, but it doesn't seem to address the issue.  It could be
that it is just Inkscape that does this and if one were to view the SVG image
in an HTML platform things are fine.  Don't know if it is that important to
research that.

I don't see the point of trying to fix the rendering part of XPDF for this
issue.  Their response is likely to be the same as the Octave-compatibility
viewpoint, i.e., that XPDF behaves the way that Acroread behaves.  Then it
becomes an issue of trying to convince Adobe that rendering needs to be fixed.
 Plus what of a half dozen more renderers in linux and Windows that might do a
similar thing?

Plus, it's not like a simple fix either.  Once one goes into the more general
world, where the triangle points may not be exactly the same then the question
becomes, "How close to the triangle edges need to be in order for us to
consider that this is supposed to be one patch?"  PDF files can be zoomed
after all.  Then it becomes an NP-search type of problem when we start talking
having to compare hundreds or even thousands of little triangles.

It makes more sense to put such effort into gl2ps to patch things back
together.  At least there the GLU tessellation triangles might still be
grouped together, thereby avoiding the NP-search.  Beyond that are still some
issues with gl2ps with the triangles and mesh lines.  See the attached
screenshot.

I don't think there is a bug here that is the responsibility of Octave.  The
best thing is to put a note in the "print" help specific to the fltk/qt
toolkits about what to expect for the output.

(file #41246)
    _______________________________________________________

Additional Item Attachment:

File name: Screenshot_from_2017-07-19_11:30:46-annotated.png Size:43 KB


    _______________________________________________________

Reply to this item at:

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

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