octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #45494] Patches have spurious (antialising) li


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #45494] Patches have spurious (antialising) lines in vector printout
Date: Tue, 18 Jul 2017 19:21:02 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

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

> > AFAIU it is pdf/eps rasterization libraries that need a fix: you could try
to find how to implement a better anti-aliasing algorithm (that doesn't take
background colors into account when two foreground polygons, triangles or not,
are adjacent) and submit it to libpoppler/xpdf developpers.

I don't think the issue is anti-aliasing.  If anything, it has to do with the
manner in which polygons are drawn/filled at the borders.

Months/years ago the last I looked at this, there is a test_gl2ps.svg file I
have, which is a display of the patch demo with a green octagon to the left
and a blue hexadecagon to the right.  If I open that in inkscape, that two has
the tessellation lines.  But the tessellation lines aren't really lines, they
are the "cracks" of space where two edges don't meet snugly and the white
background shows through.  The pixels that show through are very faint, so
look grey.  The slope of the line must determine the pattern at which there is
a space in terms of x,y coordinates--hence some slopes look like a dotted line
(crack), while others look like a solid line (crack).

The SVG file is ASCII, and it appears to me that the dimensions on the triagle
vertices all match well.  That is, well, I can show:


<polygon fill="#0000ff" points="270.185,236.602 286.386,107.82
270.185,169.663"/>
<polygon fill="#0000ff" points="286.386,107.82 270.185,236.602
286.386,298.445"/>
<polygon fill="#0000ff" points="286.386,107.82 286.386,298.445
316.321,60.4877"/>
<polygon fill="#0000ff" points="316.321,60.4877 286.386,298.445
316.321,345.777"/>
<polygon fill="#0000ff" points="316.321,60.4877 316.321,345.777
355.433,34.8715"/>
<polygon fill="#0000ff" points="355.433,34.8715 316.321,345.777
355.433,371.394"/>
<polygon fill="#0000ff" points="355.433,34.8715 355.433,371.394
397.767,34.8715"/>
<polygon fill="#0000ff" points="397.767,34.8715 355.433,371.394
397.767,371.394"/>
<polygon fill="#0000ff" points="397.767,34.8715 397.767,371.394
436.879,60.4877"/>
<polygon fill="#0000ff" points="436.879,60.4877 397.767,371.394
436.879,345.777"/>
<polygon fill="#0000ff" points="436.879,60.4877 436.879,345.777
466.814,298.445"/>
<polygon fill="#0000ff" points="436.879,60.4877 466.814,298.445
466.814,107.82"/>
<polygon fill="#0000ff" points="466.814,107.82 466.814,298.445
483.015,169.663"/>
<polygon fill="#0000ff" points="483.015,169.663 466.814,298.445
483.015,236.602"/>


See how all the vertices coincident between triangles are the same exact
value, e.g., 436.879 is consistent.  In other words, there is no rounding
effect on anyone's part along the way.

So, the driver's algorithm is probably something in which the formula of a
line is constructed directly or indirectly and anything for which w'x < c
(i.e., hyperplane notation) is colored blue.  Maybe if the driver used a
formula like w'x <= c it would give that outer edge of the triangle a little
more width somehow.  Just speculation, of course, without digging into
inkscape or ghostview code, but my point is that it's sort of the driver's
discretion of how to treat this.  It could be that the on-screen drivers
attribute more width to that triangle edge.

Is it Inscape or GhostView's responsibility to do this?  From their
perspective it might simply be, "We do solid polygons as a series of vertices,
not tessellated triangles."  And maybe that is what the "bug" is, i.e., just
the fact that many drivers with polygon support for > 3 vertices don't concern
themselves with tessellated triangle fills.  Maybe there are some control
mechanism in SVG/EPS that will make the width of the polygon's border
non-zero--I've no idea.

I can add a stroke width to the triangles:


<polygon fill="#0000ff" stroke="#0000ff" points="270.185,236.602
286.386,107.82 270.185,169.663"/>
<polygon fill="#0000ff" stroke="#0000ff" points="286.386,107.82
270.185,236.602 286.386,298.445"/>


and the tessellation "cracks" go away, but the down side is that the vertices
where triangles meet have jagged points that stick out.  Which is worse?

> > How would you handle two adjacent polygons with different colors?

Whichever is drawn second wins out, i.e., its border is a hairline thicker
than the triangle drawn underneath.

Anyway, I tested this concept as described above with SVG and the drawback is
going to be little "flares" at the vertices of polygon perimeters.  (Think of
the pointed tip of sharp angle triangles.)  It might be less drastic if we
draw lines with butt caps rather than have a stroke around the polygons, but
it will probably still be noticeable.

I'm beginning to think there is no good solution here, and that it is simply a
matter of something being lost for drivers in general with tessellation
triangles.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]