bugGNU Octave - Bugs: bug #53737, printing to svg gives error and no...

 
 

bug #53737: printing to svg gives error and no plot with gnuplot 5.2

Submitter:  Francesco Potortì <pot>
Submitted:  Tue 24 Apr 2018 12:08:28 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.2 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 26 Apr 2018 09:15:19 PM UTC, comment #36: 

This has been fixed in gnuplot.  The font name pointer was not being initialized unless there was complete success with the options.  Hence, this was a random fail depending on what ones memory looked like in the region of that pointer variable.  Thanks for catching this.

Dan Sebald <sebald>
Thu 26 Apr 2018 08:22:35 PM UTC, comment #35: 

I just tried a 5.3.0 snapshot and it does not crash for me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 26 Apr 2018 05:40:58 PM UTC, comment #34: 

Thanks, yes, I would appreciate that.

Francesco Potortì <pot>
Thu 26 Apr 2018 05:36:00 PM UTC, comment #33: 

I can reproduce with the latest git head Version 5.3 patchlevel 0    last modified 2018-04-25:


gnuplot> plot sin(x)
gnuplot> set terminal svg enhanced size 576,432 dynamic fsize 8 background rgb "#ffffff"

Terminal type is now 'svg'
                                                        ^
         unrecognized terminal option

gnuplot> set out "t1.svg"
gnuplot> replot
Segmentation fault


Would you like me to file the bug report?

Dan Sebald <sebald>
Thu 26 Apr 2018 05:06:27 PM UTC, comment #32: 

Do you get a crash if you just feed the original bad line to gnuplot? E.g. this is what i got with 5.2.2



gnuplot> plot sin(x)
gnuplot> set terminal svg enhanced size 576,432 dynamic fsize 8 background rgb "#ffffff"

Terminal type is now 'svg'
                                                        ^
         unrecognized terminal option

gnuplot> set out "t1.svg"
gnuplot> replot
gnuplot>


No crash. It does not crash from octave for me either though...

The fact that drawnow is different from print may be a more serious bug.

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Thu 26 Apr 2018 05:02:27 PM UTC, comment #31: 

I looked at the gnuplot ChangeLog, and there does seem to be some activity in the SVG font code last year:


        * term/svg.trm:  Normalize handling of terminal option "fontscale" to
        match other terminals. Remove obsolete keyword "fsize".


and you are using the most recent version, 5.2 patch level 2, so there could be something going on there.

The bug list for gnuplot is here:

https://sourceforge.net/p/gnuplot/bugs/

Search on "svg font" and see if anything looks pertinent.

However, unless you can reproduce the bug with a list of gnuplot commands, it probably isn't worth creating a new bug report.

Dan Sebald <sebald>
Thu 26 Apr 2018 04:37:05 PM UTC, comment #30: 

Thanks. I cannot reproduce it.  Inside Octave I get what I indicated in my first submission if I use print.

If instead I write


graphics_toolkit gnuplot; plot([1 2],[1 2]); axis([0 3 0 3]);
drawnow("svg", "TESTOUT.svg", "foo.gp");


then the line on which Gnuplot barfs (and dumps core) is not present in the foo.gp file, which starts with


unset multiplot;
set terminal svg enhanced size 560,420
set output 'TESTOUT.svg';


and the TESTOUT.svg file is generated without errors.

Anyway, if you think this is not so important after all, I ewill gladly stop investigating.

Francesco Potortì <pot>
Thu 26 Apr 2018 03:51:11 PM UTC, comment #29: 

drawnow("svg", "TESTOUT.svg", "foo.gp");

is what you want.  Then feed the foo.gp file into gnuplot with


@linux ~/octave/bug $ gnuplot

        G N U P L O T
        Version 5.2 patchlevel 0    last modified 2017-09-01

        Copyright (C) 1986-1993, 1998, 2004, 2007-2017
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')

Terminal type is now 'qt'
Options are '0 font "Sans,9"'
gnuplot> load 'foo.gp'


But gnuplot is fairly robust in terms of bugs, so if you have an older version there is a good chance any bug has been fixed.  gnuplot is fairly easy to build and install, so if you want the latest version, check www.gnuplot.info for the source link, which should be

https://sourceforge.net/p/gnuplot/gnuplot-main/ci/master/tree/

There should be a ChangeLog file there somewhere.

Dan Sebald <sebald>
Thu 26 Apr 2018 12:15:58 PM UTC, comment #28: 

Thanks for the info on the upcoming Octave 4.4, I'll certainly give it a try.

Again, if anyone would provide me with any hints, I'll post a bug report to Gnuplot developers

Francesco Potortì <pot>
Thu 26 Apr 2018 10:50:37 AM UTC, comment #27: 

Some basic support for transparency of patch and surface objects was added for qt and fltk and will be available in the soon to be released Octave 4.4 (no back to front sorting still).
It should work on-screen and for printing to pdf and svg files.

Markus Mützel <mmuetzel>
Group administrator
Thu 26 Apr 2018 10:22:29 AM UTC, comment #26: 

I have applied the patch to my Debian testing distribution and the problem has gone away, thanks.

By the way, I am using gnuplot rather than fltk because I need transparency, which fltk does not provide.  Is that till true?

Francesco Potortì <pot>
Thu 26 Apr 2018 09:48:49 AM UTC, comment #25: 

There is a bug in Gnuplot, too: it dumps core.

Would someone be so kind to help me build a simple test case to send to Gnuplot's maintainers?

I suppose the simplest way is to dump the instructions sent to gnuplot by the print command, but I never remember how to do that...

Francesco Potortì <pot>
Wed 25 Apr 2018 02:12:00 AM UTC, comment #24: 

Works for me on stable with gnuplot 5.2.2, thanks.

Mike Miller <mtmiller>
Group Member
Wed 25 Apr 2018 01:53:23 AM UTC, comment #23: 

OK, thanks.  Glad that one wasn't too bad.  I see in the link you posted that <length> appears a few times and there is a further link to its definition

https://developer.mozilla.org/en-US/docs/Web/SVG/Content_type#Length

which includes a <number> and further down on that page is the definition of <number> which can be at least an integer or a floating point specification, and in SVG attributes engineering notation is allowed.  So fractional font size works in SVG.

Dan Sebald <sebald>
Wed 25 Apr 2018 01:34:37 AM UTC, comment #22: 

@Dan: I pushed your patch to the stable branch here: http://hg.savannah.gnu.org/hgweb/octave/rev/f2eb8bfcccb6.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 08:34:31 PM UTC, comment #21: 

I built and installed


@linux ~/octave/bug $ gnuplot --version
gnuplot 5.2 patchlevel 0


reran the sample plot through all the -d<device> options and it behaves pretty much the same.  I didn't check any output in external programs, however.  (Years ago I posted a "demo print" somewhere that would give a list of terminals.  One could click on the terminal option in the list and it would run a demo and process the output through an appropriate external program and display the result to the user in some appropriate app.)

Dan Sebald <sebald>
Tue 24 Apr 2018 07:56:02 PM UTC, comment #20: 

@Dan: I wasn't favoring condensing, only using the same code.  What I had in mind was that the code under the case statement for "pdf" would be copied wholesale to be under "svg".

I don't see any reason why the font size can't be a floating point number (https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/font-size).  I agree with removing the restriction to round the font size.

Someone with gnuplot 5.2 will have to test your patch.

The option that is forcing the background to be white is the figure property "inverthardcopy".  As a test case, try this.


close all
graphics_toolkit gnuplot
plot (1:10, 'o-r')
set (gca, "color", "b")
set (gcf, "color", "m", "inverthardcopy", false)
print tst.png


The axes is now correctly colored, but the figure is still white.  I'll file a separate bug report about that.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 07:33:09 PM UTC, comment #19: 

@Rik: I noticed all your recent posts after the submitted changeset.  There certainly could be condensation of the

function f = font_spec (opts, varargin)

since the


    case "pdf"
      if (! isempty (opts.font) && ! isempty (opts.fontsize))
        f = sprintf ('font "%s,%d"', opts.font, opts.fontsize);
      elseif (! isempty (opts.font))
        f = sprintf ('font "%s"', opts.font);
      elseif (! isempty (opts.fontsize))
        f = sprintf ('font ",%d"', opts.fontsize);
      endif


gets rather repetitive.  However, some of them scale opts.fontsize, and so on.  To allow for possible tweaking, perhaps it is best to just leave them in groups of similar terminals rather than going for the most condensed code.  Doesn't matter to me much, but I think aiming for the most dense code might introduce a few bugs and a big long list of terminals in a case statement.

Also, not sure if you noticed, but the "background" warning shows up quite a bit, so in the patch I removed "background" whenever it was causing a warning when I tested all terminals.  The thing that has me wondering is that no matter what the figure "color" is set to the values reported to _gnuplot_print_.m are always #ffffff, i.e., white.  Is there some upstream code that is always forcing white when printing?  I'll guess that maybe Matlab is putting some non-white background on by default (maybe a light grey?) but when it comes time to print Matlab takes that color away.  However, as Octave is doing this, it means one can't specify a color for the background at print time.  Not a major concern, but one wonders why even have the background color option sent to the _print_command_.m if all it is ever going to be is (1,1,1)?  Would it make sense for 'color' to have some additional option?

Dan Sebald <sebald>
Tue 24 Apr 2018 07:22:37 PM UTC, comment #18: 

It looks like some terminals didn't get a review of their font sizes.  Or, it could be that gnuplot changed the format of font sizes for better consistency across terminals (I seem to recall that, but that may have been pretty long ago so it may be fine to just use the current syntax without worrying too much about gnuplot version--gnuplot's terminal settings never got the syntax standardization that the language commands did).  It looks like currently only "pslatex" is an odd case of gnuplot not having the "font "<name>,<size>" syntax.

Please try the attached changeset and let me know if that works.  It's all script code, so


patch -p1 < octave-gnuplot_fontformat_svgfractional_moreterms.patch


should be all that is needed; no recompile.  I went through all the terminal types in Octave to verify no extraneous warning is printed, etc.  However, if you notice any warnings or failed terminal behavior beyond SVG, let me know.

I also saw this note in the _gnuplot_print_.m file:


      ## FIXME: Why does svg format use round on the fontsize while
      ##        other terminals don't?


I don't know why this restriction other than someone along the way thought that SVG wouldn't allow fractional font sizes.  I can't find a pure definition of SVG on the Internet, but I do see in the following example someone used a font size of 1.5em:

https://vanseodesign.com/web-design/svg-text-font-properties/

<text x="430" y="100" font-family="Verdana" font-size="1.5em">SVG</text>


So, perhaps fractional is allowed.  With that in mind, I modified the _gnuplot_print_.m file to allow fractional SVG font size.  Reran this example using font sizes of 10, 10.5 and 11.  I imported the output files into Inkscape, zoomed into the numeral 3 and used the cursor placement to get some measurements of character height from te cursor position:


octave:4> test_10 = 15.66 - 8.59
test_10 =  7.0700
octave:5> test_10p5 = 19.51 - 12.08
test_10p5 =  7.4300
octave:6> test_11 = 20.57 - 12.77
test_11 =  7.8000


Either SVG does in fact allow fractional font size, or gnuplot lays out the plot such that it appears as though the font has scaled in size (or both).  So, let's remove the restriction on rounding for SVG.  That is also in the attached patch.

Lastly, I added four more entries to the list of allowable gnuplot terminals and adjusted documentation accordingly: "canvas", "cgm", "latex", "eepic".

(file #44009)

Dan Sebald <sebald>
Tue 24 Apr 2018 06:00:59 PM UTC, comment #17: 

For the Canvas terminal fsize still seems like a legitamate option, but why not make it the same as all the others?


set terminal canvas {size <xsize>, <ysize>} {background <rgb_color>}
{font {<fontname>}{,<fontsize>}} | {fsize <fontsize>}
{{no}enhanced} {linewidth <lw>}
{rounded | butt | square}
{dashlength <dl>}
{standalone {mousing} | name ’<funcname>’}
{jsdir ’URL/for/javascripts’}
{title ’<some string>’}


I don't have 5.2.2 so I won't be writing a patch because I can't easily test it.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 05:55:54 PM UTC, comment #16: 

Looks like a bug in Gnuplot also, as it dumps core on me.

Francesco Potortì <pot>
Tue 24 Apr 2018 05:55:02 PM UTC, comment #15: 

According to the 5.2 documentation for the svg terminal


set terminal svg {size <x>,<y> {|fixed|dynamic}}
{mouse} {standalone | jsdir <dirname>}
{name <plotname>}
{font "<fontname>{,<fontsize>}"} {{no}enhanced}
{fontscale <multiplier>}
{rounded|butt|square} {solid|dashed} {linewidth <lw>}
{background <rgb_color>}


So it looks like the svg terminal now resembles the other gnuplot terminals.  In that case, we could make the case statement for svg look like the one for pdf


    case "pdf"
      if (! isempty (opts.font) && ! isempty (opts.fontsize))
        f = sprintf ('font "%s,%d"', opts.font, opts.fontsize);
      elseif (! isempty (opts.font))
        f = sprintf ('font "%s"', opts.font);
      elseif (! isempty (opts.fontsize))
        f = sprintf ('font ",%d"', opts.fontsize);
      endif


If necessary, could add a feature to _gnuplot_has_feature_ and then test for it before using the old syntax or the new syntax.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 05:45:35 PM UTC, comment #14: 

It doesn't need to be provided by all terminals.


grep -Prn '\bfsize\b' *
plot/util/private/__gnuplot_print__.m:268:        f = sprintf ('fname "%s" fsize %d', opts.font, fontsize);
plot/util/private/__gnuplot_print__.m:273:        f = sprintf ("fsize %d", fontsize);
plot/util/private/__gnuplot_print__.m:324:        f = sprintf ("fsize %d", opts.fontsize);


And if you look at the code around lines 268 and 273


    case "svg"
      ## FIXME: Why does svg format use round on the fontsize while
      ##        other terminals don't?
      if (! isempty (opts.font) && ! isempty (opts.fontsize))
        fontsize = round (opts.fontsize * 0.75);
        f = sprintf ('fname "%s" fsize %d', opts.font, fontsize);
      elseif (! isempty (opts.font))
        f = sprintf ('fname "%s"', opts.font);
      elseif (! isempty (opts.fontsize))
        fontsize = round (opts.fontsize * 0.75);
        f = sprintf ("fsize %d", fontsize);
      endif


So it may be that replacing fsize with fontscale just for the svg terminal is the correct thing to do.

The other occurrence is for the Canvas terminal at line 324


    case "canvas"
      if (! isempty (opts.fontsize))
        f = sprintf ("fsize %d", opts.fontsize);
      endif




Rik <rik5>
Group administrator
Tue 24 Apr 2018 05:34:18 PM UTC, comment #13: 

That actually seems to be a scaling factor applied to the current font size, not a font size by itself.  And I'm not sure whether that option is consistently provided for all terminals.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 05:23:59 PM UTC, comment #12: 

This is in the NEWS file for gnuplot 5.2

> * CHANGE svg terminal option "fontscale" replaces obsolete "fsize"


The "fontscale" option is not present in gnuplot 5.0.

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 05:18:16 PM UTC, comment #11: 

Release notes for gnuplot are at http://gnuplot.info/ReleaseNotes_5_2_2.html

Quoting from the notes:


Backward compatibility

Gnuplot development assigns very high priority to backward compatibility with earlier versions. However changes introduced in version 5 can affect the operation of some version 4 scripts. Please see section "Differences from Version 4" in the User Manual.



Rik <rik5>
Group administrator
Tue 24 Apr 2018 05:17:50 PM UTC, comment #10: 

Sorry, I was commenting on the Octave expression, not the change in gnuplot font syntax.

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 05:10:27 PM UTC, comment #9: 

I downgraded to gnuplot 5.0.3 and I can confirm that the same expression works perfectly with Octave 4.3.91. With gnuplot 5.2 it aborts with the error message shown and the svg file is empty.

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 05:01:57 PM UTC, comment #8: 

Rik: Does 5.0.x accept these kinds of font specifications as well, or was there an incompatible change going from 5.0.x to 5.2.x?  If so, then it becomes even more difficult to support these different versions.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 04:58:53 PM UTC, comment #7: 

It looks like Octave assumes "fsize N" can be used to set the font size independent of the font name.  But now it looks like the syntax for the svg terminal is documented to be


font "<fontname>{,fontsize}"


where {} indicates the element is optional.  For the canvas terminal, the doc string says


font {<fontname>}{,<fontsize>}


which appears to indicate that the name is optional?  For the x11 terminal, it is


font <fontspec>


For epslatex it is


{font} "fontname{,fontsize}" {<fontsize>}


and pdfcairo just says


font <font>


whatever that means.

I didn't check every terminal type mentioned in _gnuplot_print_.m, but this looks like a lot of trouble to support properly.

John W. Eaton <jwe>
Group administrator
Tue 24 Apr 2018 04:40:06 PM UTC, comment #6: 

I also have gnuplot 5.2.2. I will see if I can test with a copy of 5.0.

Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 04:38:10 PM UTC, comment #5: 

It definitely works for me.  My gnuplot version is 5.0.3.  The OP's was 5.2.2.  What version of gnuplot are you running?

Rik <rik5>
Group administrator
Tue 24 Apr 2018 04:26:47 PM UTC, comment #4: 

Rik - are you sure? I get the exact same error with 4.3.91


>> graphics_toolkit gnuplot; plot([1 2],[1 2]); axis([0 3 0 3]);
>> print("test.svg");

gnuplot> set terminal svg enhanced size 576,432 dynamic fsize 8 background rgb "#ffffff"
                                                        ^
         line 0: unrecognized terminal option


Mike Miller <mtmiller>
Group Member
Tue 24 Apr 2018 04:09:59 PM UTC, comment #3: 

The plotting and printing for gnuplot is spread over a number of files.  I don't know which particular one fixed it, so you might just want to grab them all.


./plot/util/private/__gnuplot_has_feature__.m
./plot/util/private/__gnuplot_version__.m
./plot/util/private/__gnuplot_print__.m
./plot/util/private/__gnuplot_ginput__.m
./plot/util/private/__gnuplot_has_terminal__.m
./plot/util/private/__gnuplot_open_stream__.m
./plot/util/private/__gnuplot_draw_figure__.m
./plot/util/private/__gnuplot_draw_axes__.m
./plot/util/private/__gnuplot_get_var__.m
./plot/util/__gnuplot_drawnow__.m


You can use the web interface to Mercurial to grab the files at http://hg.savannah.gnu.org/hgweb/octave/file/d73dfd34230b



Rik <rik5>
Group administrator
Tue 24 Apr 2018 03:55:12 PM UTC, comment #2: 

Would you be so kind to point me to the changed .m file, so I can just take that one?

Francesco Potortì <pot>
Tue 24 Apr 2018 03:31:17 PM UTC, comment #1: 

Happily, this has already been fixed on the stable branch that is about to be release as 4.4.0.  You can try the release candidate if you want to verify, or just wait for 4.4.0.

Marking as fixed and closing report.

Rik <rik5>
Group administrator
Tue 24 Apr 2018 12:08:28 PM UTC, original submission:  

These simple statements give an erro and make gnuplot dump core:


octave> graphics_toolkit gnuplot; plot([1 2],[1 2]); axis([0 3 0 3]); print("test.svg");

gnuplot> set terminal svg enhanced size 576,432 dynamic fsize 8 background rgb "#ffffff"
                                                        ^
         line 0: unrecognized terminal option

octave> system([ gnuplot_binary " -V"]);
gnuplot 5.2 patchlevel 2



Francesco Potortì <pot>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by sebald (Updated the item)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pot (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-26 mtmiller Carbon-CopyRemoved 80942 -
    2018-04-25 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-04-24 sebald Attached File- Added octave-gnuplot_fontformat_svgfractional_moreterms.patch, #44009
    2018-04-24 mtmiller StatusFixed Confirmed
        Open/ClosedClosed Open
        Summaryprinting to svg gives error and no plot, gnuplot dumps core printing to svg gives error and no plot with gnuplot 5.2
    2018-04-24 rik5 StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code