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

[Dan Sebald]

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

Interesting find Dmitri.  Some observations:

1) The size and time of loading for the -dpdfwrite file.  I did the
-dpsc/-dpdf thing, which perhaps is different from this -dpdfwrite.  The info
within the PS file is:

%%Creator: GPL Ghostscript 910 (ps2write)

So, we are starting to get intermediary tools here that could also be a source
of artifacts.  Is gl2ps using some additional tools outside its control?

2) Why is this -dpdflatexstandalone better?  I've replicated your result,
i.e., a very nice PDF image--with and without line smoothing.  I've also
confirmed in various ways that when acroread and xpdf render, it is drawing
small individual triangles and not some binary image representation of the
drawing.

It looks like you compiled the LaTeX code to create the final image.  I'm
analyzing just the PDF file generated.


dan-t1-inc.pdf
--------------
Viewed in Acroread:
  Looks good, renders quickly, individual triangles
Printed to PostScript from Acroread:
  Looks good in gv, renders moderately fast, individual
  triangles no lines/cracks.  The only odd thing is a
  little waviness of the interior edge
Examine PostScript code:
  Big file, all sorts of lines drawn.  The odd thing is
  that there appear to be 350 "img" images within.  I
  don't know what that is about.  Again, I see individual
  triangles being drawn.  At the top of the file is:

  %%Creator: Adobe Acrobat 9.5.3
  [snip]
  %%DocumentNeededResources: (atend)
  %%DocumentSuppliedResources: (atend)
  %%DocumentNeededFeatures: (atend)
  %%DocumentSuppliedFeatures: (atend)
  [snip]
  %%BeginResource: procset Adobe_AGM_Utils 1.0 0
  %%Version: 1.0 0
  %%Copyright: Copyright(C)2000-2006 Adobe Systems, Inc. All Rights Reserved.

Viewed in Xpdf:
  Looks good, renders quickly, individual triangles.
Printed to PostScript from Xpdf:
  Shows lines/cracks in gv and takes about 8 seconds to
  render.  Viewing the code in an editor, it appears to
  be only geometric descriptions, a bit long list of them.
  That is, no binary images.  At the top is the following:

  %Produced by poppler pdftops version: 0.24.5
(http://poppler.freedesktop.org)
  [snip]
  %%Copyright: Copyright 1996-2011 Glyph & Cog, LLC


Q: What is Glyph & Cog's role in this?  pdftops is using one of its
products?  gl2ps is using one of their products?

What can be taken away from this?  With complete certainly, probably not too
much, but my hypothesis is

1) In PDF perhaps there is such a thing as a tessellated surface, hence the
nice PDF files for -pdflatexstandalone.  But it could be that PS doesn't have
such a feature...i.e., PS has been frozen for a quite a while and was defined
years ago.

2) Whatever software is generating the PDF of -pdflatexstandalone knows how to
generate such tessellated surface.

3) Both Acroread and Xpdf can interpret such tessellated surface within a PDF
file.  The former should go without saying, but that Xpdf can do so too is
good.

3) When creating PS from said tessellated surface, Acroread is doing some kind
of trick to produce a nice PostScript result, whereas Xpdf is going with the
basic bunch of triangles approach.  In other words, poppler pdftops is using
the technique that we know suffers from cracks/lines.

I'm interested in knowing more, as it would be nice for gnuplot to fix its PDF
output to get rid of the lines/cracks it has underneath the black mesh lines.

    _______________________________________________________

Reply to this item at:

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

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