bugGNU Octave - Bugs: bug #53023, Marker symbols not fully drawn for...

 
 

bug #53023: Marker symbols not fully drawn for some output formats

Submitter:  Rik <rik5>
Submitted:  Tue 30 Jan 2018 07:25:01 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Feb 2018 04:07:11 PM UTC, comment #24: 

Closing report.

Rik <rik5>
Group administrator
Tue 06 Feb 2018 09:11:41 AM UTC, comment #23: 

I pushed the patch here:

http://hg.savannah.gnu.org/hgweb/octave/rev/800876b7132c

after fixing the copy/paste error. The "." marker has no line contour so it is not possible to use the same trick. We can eventually increase the default number of polygon edges to make it "rounder".

Pantxo Diribarne <pantxo>
Group Member
Mon 05 Feb 2018 10:42:42 PM UTC, comment #22: 

This looks good.  I have two items to check before you commit it.

1) Shouldn't the marker '.' be included in the list of rounded cornermarkers?  It is drawn the same way that 'o' is and that marker is in the rounded list.

2) There is a cut and paste error.  The letter 'p' should be checked for to indicate pentagram.  Instead the letter 'h' is being checked twice.


+      if (m == "o" || m == "v" || m == "^" || m == ">" || m == "<" || m == "h"
+          || m == "hexagram" || m == "h" || m == "pentagram")
+        {
+          set_linejoin ("round");
+          set_linecap ("round");
+        }
+      else
+        {
+          set_linejoin ("miter");
+          set_linecap ("square");
+        }



Rik <rik5>
Group administrator
Mon 05 Feb 2018 03:42:37 PM UTC, comment #21: 

I attached an updated patch. I chose square linejoin and linecap unless the marker contour (if any) has no right angles.

(file #43178)

Pantxo Diribarne <pantxo>
Group Member
Wed 31 Jan 2018 06:57:58 PM UTC, comment #20: 

I think adjusting the linecap and linejoin is a good first step to resolving this.  With Pantxo's patch I tried


plot (1:10, 'x-', 'linewidth', 10, 'markersize', 18)
print tst.png


The 'X' marker comes out rounded, of course, since that is the linecap value used.  However, I think more people would prefer hard edges on the 'X' marker.  All this means is that I think Pantxo's approach is correct, but maybe we could optimize it a bit further by having the particular linecap chosen based on marker type in make_marker_list().



Rik <rik5>
Group administrator
Wed 31 Jan 2018 06:17:11 PM UTC, comment #19: 

Oops, for the last post the code I used was


hl = plot (1:10, "o-", "linewidth", 10, "markersize", 18);
print tst.png


I tested the patch in comment #16 and it resolves the issue in the code above.


Rik <rik5>
Group administrator
Wed 31 Jan 2018 06:11:37 PM UTC, comment #18: 

Certainly a linewidth of 36 is pathological, but I get artifacts even when the markersize is larger than the linewidth.




Rik <rik5>
Group administrator
Wed 31 Jan 2018 05:17:42 PM UTC, comment #17: 

I'm attaching a screenshot of what I see for the Inskape example


plot (1:10, "-s", "markersize", 10)
print toto.svg


It's the upper-left corner of the square marker that doesn't join. 

I picked a marker at the corner of the axes to show that those axes lines are probably drawn individually as well as opposed to one continuous closed path for the rectangle.

My gl2ps is 1.3.8, so I can't test the patch.

I agree that a lot of time is required to handle these line-join/path details.


Dan Sebald <sebald>
Wed 31 Jan 2018 11:19:04 AM UTC, comment #16: 

@Rik:
OpenGL linestrip  primitives don't have any feature like linecap or linejoin (see bug #39643). So this is an undefined behavior and the way line junctions and endings are rendered may depend on the OpenGL rendering library in use. I don't think we should care too much about the case of markers that have contour lines wider than the diameter of the marker itself ... this is a pathological case where the workaround is clearly to change the size of the marker so that it fits (looks good) with its associated line.
The proposition of using round linecap and linejoin may be useful anyway:


plot (1:10, "-s", "markersize", 10)
print toto.svg


If you inspect the svg output in inkscape you'll see that not all corners of the marker join gracefully.
I attached a first patch for rounding markers, that will only work if you have gl2ps>=1.4.

@Dan: I think the closepath route is the way to go in the future but by patching gl2ps to offer some functions like "gl2psBegin(End)ClosedPath" so that gl2ps can be told when to interpret a line series as a closed contour. This is the only reliable way to handle all output formats.

(file #43138)

Pantxo Diribarne <pantxo>
Group Member
Wed 31 Jan 2018 07:17:31 AM UTC, comment #15: 

I forgot the Okular screenshot for Rik's original lw36.pdf.


Dan Sebald <sebald>
Wed 31 Jan 2018 07:15:12 AM UTC, comment #14: 

"A possible workaround is to use "round" linecap and linejoin for markers."

Just pointing out that okular is doing the "round" linecap.  Attached is a screenshot of zoomed okular at that missing pie wedge.  One can see that there is a little curve at that location.  There are two overlapping round linecaps...and note that the linecaps don't quite line up the outside edges of the line (more about this below).  It may be that Octave's generating markers without any type of linecap specified and it is left up to the viewer to choose what it wants (xpdf displays the same as okular).

I'm also attaching a slightly modified EPS version where I changed (LC stands for setlinecap):


linux@ ~/octave/bug/53023 $ diff -u lw36.epsc djs_capped_marker_lw36.epsc
--- lw36.epsc        2018-01-31 00:10:45.035322545 -0600
+++ djs_capped_marker_lw36.epsc        2018-01-31 00:11:27.787322964 -0600
@@ -277,7 +277,7 @@
 521.28 47.52 LS
 521.28 399.6 LE
 36 W
-0 LC
+1 LC
 1 LJ
 [] 0 setdash
 0 0.447 0.741 C


View both lw36.epsc and djs_capped_marker_lw36.epsc in ghostview (gv) and you'll see that the latter is similar to Rik's PDF result.

I then ran djs_capped_marker_lw36.epsc through ps2pdf and looked at that result in okular.  I can tell there is still a bit of rounding--as with lw36.pdf--(it actually bulges outward a tad) but the line caps line up much better than with lw36.pdf.  That suggests alignment isn't necessarily a viewer issue, but probably the difference between ps2pdf and Octave's PDF prind direct.

And then I explored using "closepath" to avoid the cap issue and made the following change (back to 0 LC, by the way):


linux@ ~/octave/bug/53023 $ diff -u lw36.epsc djs_closed_marker_lw36.epsc
--- lw36.epsc        2018-01-31 00:10:45.035322545 -0600
+++ djs_closed_marker_lw36.epsc        2018-01-31 01:03:18.251353405 -0600
@@ -290,6 +290,7 @@
 335.28 252.9 L
 372.48 282.24 L
 409.68 311.58 L
+closepath
 446.88 340.92 LE
 115.08 76.86 LS
 114.507 75.0966 L
@@ -301,6 +302,7 @@
 111.153 79.7132 L
 113.007 79.7132 L
 114.507 78.6234 L
+closepath
 115.08 76.86 LE
 152.28 106.2 LS
 151.707 104.437 L
@@ -312,6 +314,7 @@
 148.353 109.053 L
 150.207 109.053 L
 151.707 107.963 L
+closepath
 152.28 106.2 LE
 189.48 135.54 LS
 188.907 133.777 L
@@ -323,6 +326,7 @@
 185.553 138.393 L
 187.407 138.393 L
 188.907 137.303 L
+closepath
 189.48 135.54 LE
 226.68 164.88 LS
 226.107 163.117 L
@@ -334,6 +338,7 @@
 222.753 167.733 L
 224.607 167.733 L
 226.107 166.643 L
+closepath
 226.68 164.88 LE
 263.88 194.22 LS
 263.307 192.457 L
@@ -345,6 +350,7 @@
 259.953 197.073 L
 261.807 197.073 L
 263.307 195.983 L
+closepath
 263.88 194.22 LE
 301.08 223.56 LS
 300.507 221.797 L
@@ -356,6 +362,7 @@
 297.153 226.413 L
 299.007 226.413 L
 300.507 225.323 L
+closepath
 301.08 223.56 LE
 338.28 252.9 LS
 337.707 251.137 L
@@ -367,6 +374,7 @@
 334.353 255.753 L
 336.207 255.753 L
 337.707 254.663 L
+closepath
 338.28 252.9 LE
 375.48 282.24 LS
 374.907 280.477 L
@@ -378,6 +386,7 @@
 371.553 285.093 L
 373.407 285.093 L
 374.907 284.003 L
+closepath
 375.48 282.24 LE
 412.68 311.58 LS
 412.107 309.817 L
@@ -389,6 +398,7 @@
 408.753 314.433 L
 410.607 314.433 L
 412.107 313.343 L
+closepath
 412.68 311.58 LE
 449.88 340.92 LS
 449.307 339.157 L
@@ -400,6 +410,7 @@
 445.953 343.773 L
 447.807 343.773 L
 449.307 342.683 L
+closepath
 449.88 340.92 LE
 grestore
 grestore


Have a look at djs_closed_marker_lw36.epsc in ghostview (gv) and it looks good.  The closepath on the marker is the way to go.

I will also add that it is a good idea to not repeat the marker draw with absolute coordinates, but instead (IIRC) define the marker in terms of terms of relative coordinates (say it is /MARK1 and then use that definition later in the PostScript code. That would be a tedious code change though.  (I've programmed in PostScript before, oy.)

(file #43132, file #43133, file #43134, file #43135)

Dan Sebald <sebald>
Wed 31 Jan 2018 01:01:52 AM UTC, comment #13: 

Sorry -- I got confused...

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Wed 31 Jan 2018 12:58:53 AM UTC, comment #12: 

The "Producer" is "GPL Ghostscript 9.18" so this went gl2ps->postscript and postscript->pdf.  If I use -dpdflatexstandalone and then use pdfinfo on the resulting file I get


Title:          gl2ps_renderer figure
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       Octave



Rik <rik5>
Group administrator
Wed 31 Jan 2018 12:34:09 AM UTC, comment #11: 

Hmm. That was lw36.pdf created on my computer.
Rik's pdf is a direct export:



pdfinfo lw36.pdf
Title:          gl2ps_renderer figure
Author:         Octave
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       GPL Ghostscript 9.18
CreationDate:   Tue Jan 30 12:11:35 2018 CST
ModDate:        Tue Jan 30 12:11:35 2018 CST


how come?
octave:2> _octave_config_info_ ("hg_id")
ans = 3ceee1910e1a

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Wed 31 Jan 2018 12:27:03 AM UTC, comment #10: 

I confirm that lw36.pdf looks fine in okular.
Okular also coredumps on the lw36.(e)psc so I cannot tell how it renderas those...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 31 Jan 2018 12:20:29 AM UTC, comment #9: 

That issue ccame up some time ago -- default print always goes through ghostscript. -dpdflatexstandalone goes directly to pdf.
Pantxo Diribarne has some explanation why, but I forgot the details and I cannot find the thread.


pdfinfo t3-inc.pdf
Title:          gl2ps_renderer figure
Creator:        GL2PS 1.4.0, (C) 1999-2017 C. Geuzaine
Producer:       Octave
CreationDate:   Tue Jan 30 17:56:35 2018 CST
Tagged:         no
...

pdfinfo lw36.pdf
Producer:       GPL Ghostscript 9.22
CreationDate:   Tue Jan 30 17:56:11 2018 CST
ModDate:        Tue Jan 30 17:56:11 2018 CST
Tagged:         no
...


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 31 Jan 2018 12:18:12 AM UTC, comment #8: 

@Dmitri: Apparently my PDF viewer (Okular) is helpfully filling in the rest of the marker.  On my computer lw36.pdf looks different from all the others, but it is actually better if all formats have the same problem.  It means there is only one place where this needs to be resolved.

Rik <rik5>
Group administrator
Wed 31 Jan 2018 12:12:21 AM UTC, comment #7: 

I follow Dmitri's suggestions and always use
print zzz.pdf. I am not sure if the -dpdflatexstandalone
is always needed. But the path through ghostscript is not
likely to work correctly in my environment.

Michael Godfrey <godfrey>
Group Member
Wed 31 Jan 2018 12:00:16 AM UTC, comment #6: 

But your pdf looks as bad as others. You can export directly to pdf if you do "print -dpdflatexstandalone t3.pdf" The resulting t3-inc.pdf is attached (looks different). This is with both
LIBGL_ALWAYS_SOFTWARE=1 LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0

Dmitri.
--


(file #43125)

Dmitri A. Sergatskov <dasergatskov>
Tue 30 Jan 2018 11:52:28 PM UTC, comment #5: 

"export to pdf" meant "print tst.pdf".  I'm surprised it was any different because I thought Octave was always using gl2ps->postscript and then ghostscript to change the postcript in to other formats.  But maybe we are using gl2ps->pdf directly.

Rik <rik5>
Group administrator
Tue 30 Jan 2018 11:44:25 PM UTC, comment #4: 

My recent experience using current fc27 both locally
and remote is that both:

LIBGL_ALWAYS_SOFTWARE=Yes
export LD_PRELOAD=/usr/lib64/libGLX_mesa.so.0

are required. One of these works in some contexts and
the other in others. If are used I get good results.

Michael Godfrey <godfrey>
Group Member
Tue 30 Jan 2018 10:50:26 PM UTC, comment #3: 

Rik, what do you mean by "export to pdf". Is it "Save As" pdf file from qt plot window? I get the same problem as print to pdf.
Also, if I do not set "LIBGL_ALWAYS_SOFTWARE=1" the figure on screen does not look like the print outputs. It looks as expected (?) if I do use software renderer. The "Save as" pdf still looks bad.

See attached.

This is on Fedora 27 with i7/amd graphics and all fairly recent libraries. (QT 5.9.2)

Dmitri.
--



file #43121,

Dmitri A. Sergatskov <dasergatskov>
Tue 30 Jan 2018 10:01:03 PM UTC, comment #2: 

Why does it not show up on-screen?  Is there a different linecap or linejoin being used for display versus printing?

From gl-render.cc:


    case 'o':
        {
          int div = static_cast <int> (M_PI * sz / 4);
          if (! (div % 2))
            div += 1;               // ensure odd number for left/right symmetry
          div = std::max (div, 5);  // ensure at least a few vertices are drawn
          double ang_step = M_PI / div;

          glBegin (filled ? GL_POLYGON : GL_LINE_LOOP);
          for (double ang = 0; ang < 2*M_PI; ang += ang_step)
            glVertex2d (sz/2*cos (ang), sz/2*sin (ang));
          glEnd ();
        }


GL_LINE_LOOP is suppose to join the first and last vertex with a line segment.  Is that not happening?  We could always use GL_LINE_STRIP and supply more vertices than necessary so that OpenGL paints over an extra bit of screen.

I tried with filled markers, so that GL_POLYGON is used, and the results are better.  There is still a small white indent, however, taken out of the circle.

Rik <rik5>
Group administrator
Tue 30 Jan 2018 09:47:39 PM UTC, comment #1: 

Actually, the contour of the marker (a set of consecutive line primitives) is interpreted by gl2ps as being part of a polyline, not a loop. There is no junction between the line ends and this turns out to be much more visible with a large line width.
A possible workaround is to use "round" linecap and linejoin for markers.

Pantxo Diribarne <pantxo>
Group Member
Tue 30 Jan 2018 07:25:01 PM UTC, original submission:  

Using this simple test script,


close all
graphics_toolkit qt
hl = plot (1:10, "o-", "linewidth", 36);
axis ([0, 12, 0, 12]);
print lw36.svg
print lw36.epsc
print lw36.psc
print lw36.pdf


, I find that one of the markers is not fully drawn when exporting to certain formats.  Instead of being a full circle, there is a pie wedge removed.  The export to pdf gets it right.

This might be an upstream bug in gl2ps.



Rik <rik5>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #43178:  roundmarkers2.patch added by pantxo (2KiB - text/x-patch)
file #43144:  X.marker.png added by rik5 (16KiB - image/png)
file #43143:  tst.roundlinejoin.png added by rik5 (14KiB - image/png)
file #43142:  tst.png added by rik5 (14KiB - image/png)
file #43138:  roundmarkers.patch added by pantxo (710B - text/x-patch)
file #43132:  djs_capped_marker_lw36.epsc added by sebald (9KiB - application/octet-stream)
file #43133:  djs_capped_marker_lw36.epsc.pdf added by sebald (4KiB - application/pdf)
file #43134:  djs_closed_marker_lw36.epsc added by sebald (9KiB - application/octet-stream)
file #43135:  djs_closed_marker_lw36.epsc.pdf added by sebald (4KiB - application/pdf)
file #43125:  t3-inc.pdf added by dasergatskov (6KiB - application/pdf)
file #43120:  hw_gl_screen.png added by dasergatskov (20KiB - image/png)
file #43121:  soft_saveas.pdf added by dasergatskov (4KiB - application/pdf)
file #43122:  soft_gl_screen.png added by dasergatskov (26KiB - image/png)
file #43118:  lw36.pdf added by rik5 (4KiB - application/pdf)
file #43114:  tst_lw.m added by rik5 (155B - text/x-matlab)
file #43115:  lw36.psc added by rik5 (165KiB - application/octet-stream)
file #43116:  lw36.svg added by rik5 (11KiB - image/svg+xml)
file #43117:  lw36.epsc added by rik5 (9KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by dasergatskov (Updated the item)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-06 rik5 Open/ClosedOpen Closed
    2018-02-06 pantxo StatusPatch Reviewed Fixed
    2018-02-05 rik5 StatusPatch Submitted Patch Reviewed
    2018-02-05 pantxo Attached File- Added roundmarkers2.patch, #43178
        StatusConfirmed Patch Submitted
    2018-01-31 rik5 Attached File- Added X.marker.png, #43144
    2018-01-31 rik5 Attached File- Added tst.roundlinejoin.png, #43143
    2018-01-31 rik5 Attached File- Added tst.png, #43142
    2018-01-31 sebald Attached File- Added djs_Marker_Northwest_Corner_Connect_Screenshot_from_2018-01-31_11-05-59.png, #43141
    2018-01-31 pantxo Attached File- Added roundmarkers.patch, #43138
    2018-01-31 sebald Attached File- Added okular_zoom_pie_wedge_Screenshot_from_2018-01-31_00-01-01-djs2018jan31.png, #43136
    2018-01-31 sebald Attached File- Added djs_capped_marker_lw36.epsc, #43132
        Attached File- Added djs_capped_marker_lw36.epsc.pdf, #43133
        Attached File- Added djs_closed_marker_lw36.epsc, #43134
        Attached File- Added djs_closed_marker_lw36.epsc.pdf, #43135
    2018-01-31 dasergatskov Attached File- Added t3-inc.pdf, #43125
    2018-01-30 dasergatskov Attached File- Added hw_gl_screen.png, #43120
        Attached File- Added soft_saveas.pdf, #43121
        Attached File- Added soft_gl_screen.png, #43122
    2018-01-30 pantxo StatusNone Confirmed
    2018-01-30 rik5 Attached File- Added lw36.pdf, #43118
    2018-01-30 rik5 Attached File- Added tst_lw.m, #43114
        Attached File- Added lw36.psc, #43115
        Attached File- Added lw36.svg, #43116
        Attached File- Added lw36.epsc, #43117

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code