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

[Dan Sebald]

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

Dmitri is correct; the differences you are seeing is a viewer issue.  Turn
anti-aliasing off to get a view of everything that is present because
otherwise thin, faint lines get lowpass-filtered out of the display.

I looked at the link I posted below as a reminder of what is at play here. 
GLU is the OpenGL library extension (i.e., it's not the OpenGL graphics
primitives) but uses them to achieve slightly higher functionality, one of
them being the general patch fill.  GLU is most likely the software
introducing the tessellation lines you see.  The proper thing would be to fix
the GLU library (or the primitives if it goes that far).  However, as I
probably pointed out elsewhere, I've tried providing OpenGL developers with
fixes to other problems and found it hard to sway people working on that
project.

Another alternative I thought of was to first detect any shapes which are
convex because OpenGL has a routine that fills convex shapes, i.e., no
tessellation required.  In the example you've given, I believe most shapes are
going to be convex because they are translations of squares from a mesh
surface.  (Four points can transform to a non-convex shape rather easily, but
generally that isn't too common with reasonable surfaces when resolution is
chosen properly.)  There is a hunk of prototype code here:

https://savannah.gnu.org/bugs/download.php?file_id=33583

Such an approach won't totally eliminate the issue of the tessellation lines
for strange surfaces if there happen to be some non-convex shapes, but for the
most part it should remove them.

Regarding eps->pdf conversion, that comes from a design which simplified the
matter of support for all output file formats by using one strategy of first
creating and EPS file then converting that file whatever format that
image-magick converter can handle, which is just about everything.  So
image-magick does most of the work, but the limitation is the quality of gl2ps
image and there aren't any vector-based outputs.  This idea of EPS->all was
extended to the gnuplot toolkit as well.  I didn't like that change because it
really degraded the quality of output figures such as LaTeX and SVG, no less
in the general sense if there are image-magick library quirks.  I think
gnuplot toolkit plot format richness has been restored.  I also created a GUI
demo that prints to any of the formats that gnuplot produces then issue system
commands to externally process the example output files.  That's not currently
in the latest repository, but it's nice in that users can seek out the code of
the demo to see how LaTeX figures, etc. should be used.

    _______________________________________________________

Reply to this item at:

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

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