bugGNU Octave - Bugs: bug #52193, Font choices are ignored when...


bug #52193: Font choices are ignored when printing to an image file

Submitted by:  Etienne Dechamps <edechamps>
Submitted on:  Sun 08 Oct 2017 02:05:35 PM UTC  
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Mon 19 Feb 2018 11:06:01 PM UTC, comment #26:

I don't have time to work on this just now, but I think the merging algorithm can be improved to handle this. It relies on gl2ps putting out the vertices in a very specific order, but relaxing that condition is probably enough to make this work.

Rik <rik5>
Project Administrator
Mon 19 Feb 2018 10:59:35 PM UTC, comment #25:

I just tested latest mergepoly.pl script which checks edges and it is better than the first version which checked only points, but there are still gaps in the output.

My guess is that because this scene has so many polygons the ordering in the output svg file is not split perfectly. Sometimes a polygon for a background triangle might be followed not by another background triangle, but by a foreground triangle. In this case, the merge polygon algorithm detects different colors or different vertices and refuses to join the polygons.

We probably need a more intelligent merging algorithm which, alas, means more complicated.

Rik <rik5>
Project Administrator
Mon 19 Feb 2018 10:26:27 PM UTC, comment #24:

@Rik: I tested the latest version of merpoly.pl with "demo hold 6" and there are apparently missing triangles. I attached the original and modified svg files I obtain with the following commands:

(file #43366, file #43367)

Pantxo Diribarne <pantxo>
Project Member
Mon 19 Feb 2018 09:20:35 PM UTC, comment #23:

Attached is a slightly improved version of mergepoly.pl that checks whether two polygons have an edge in common, rather than just a vertex.

(file #43363)

Rik <rik5>
Project Administrator
Wed 14 Feb 2018 06:00:09 AM UTC, comment #22:

Attached is my Perl script mergepoly.pl which seems to do a fine job of reconstructing polygons.

Sample code:

And in the shell

The original file tst.svg has hundreds of polygons and lots of hairlines; The reconstructed version tst2.svg is quite smooth.

Since I only used regular expressions this could be done in Octave as well. We don't have an O(1) hash function like Perl, but using containers.Map is O(log2(N)) which should still be quick for the number of vertices involved.

(file #43287)

Rik <rik5>
Project Administrator
Tue 13 Feb 2018 06:48:14 PM UTC, comment #21:

I think a reasonable way to obtain svg output, and handle the artifacts, may be to use a separate program (svg2svg) which just does polygon reconstruction, and then a separate Qt program to change svg2any_format.

I reviewed octave-svgconvert.cc which was a hodge-podge of C, C++, and Qt styles (printf as well as std::cerr as well as QDebug). I modified things to follow Octave coding conventions, but it is still not perfect. It is attached.

The issue that I encounter with thin hairlines is triggered when the svg file contains multiple polygons in a row, but they are not necessarily related. The algorithm in octave-svgconvert.cc is too simple and only checks for whether the colors of the polygon are the same before trying to merge them. The attached bar.svg was generated by gl2ps for a stacked bar graph. It has polygons (rectangles) which are physically separated, but which appear next to each other in the svg and so are merged. I believe it is necessary to put an additional check that two polygons to be merged have at least one vertex in common.

I started writing a polygon reconstruction script in Perl (svg2svg). I've made good progress. The svg is so simple that regular expressions suffice to do the processing rather than using a full xml interpreter. But the merging of polygons is more difficult than I thought and I don't have the time to work on this just now.

I propose that this bug be a topic that we take up during one of the code sprints during OctConf 2018 in 4 weeks.

(file #43273, file #43274)

Rik <rik5>
Project Administrator
Wed 17 Jan 2018 09:42:44 AM UTC, comment #20:

@Rik: I won't have any time to work on Octave until the beginning of February, but to answer your questions:

  • 1- svg2svg is a good idea (and it would help in debugging also)
  • 2- I don't see any artifact with your test code (I attached the pdf I obtain)
  • 3- I don't observe any issue here either (file attached). I suspect this is due to a change in the way Qt5 interprets units between the version I use (5.2) and the version you and Dmitri use (5.9?). It looks like the same scaling problem I observed in Dmitri's outputs (see comment #14 and comment #15).

(file #42933, file #42934)

Pantxo Diribarne <pantxo>
Project Member
Wed 17 Jan 2018 12:17:57 AM UTC, comment #19:

@Pantxo: I am in need of better printouts using the qt toolkit so I took a look again at this bug report.

I had some questions:

1) Is it possible, or does it make sense, to also have an svg-to-svg converter to coalesce polygons for svg output? I currently print to svg because I often need to slightly tweak the figures that are produced before eventual printing to either pdf or png format. Because octave-svgconverter is designed only for svg->other formats the advantages of the removal of excess polygons are not available.

2) When using the dot '.' marker there are many, many falsely created lines. Sample code:

I can workaround it by setting the marker to 'o' and setting 'markerfacecolor' to a color value, but that is a pain.

3) Is the PaperPosition property respected? I tried

The svg file contains the whole sombrero image, but the pdf is truncated at the top. This may be just generic bad positioning that existed before this patch.

Rik <rik5>
Project Administrator
Sat 18 Nov 2017 07:06:51 PM UTC, comment #18:

Attached screenshots.


(file #42425, file #42426)

Dmitri A. Sergatskov <dasergatskov>
Sat 18 Nov 2017 07:05:52 PM UTC, comment #17:

I also looked at those antialiasing issues.
It is quite possible that we cannot do anything about unless we
represent the surface with an embedded bitmap.
In "okular" (https://okular.kde.org/) one can disable antialiasing
on the images. The the white superficial mesh would dissapear, but
ts1.psd and ts1_crop.pdf would have some artifact lines which are not in inkscape converted files (see attached).


Dmitri A. Sergatskov <dasergatskov>
Sat 18 Nov 2017 06:58:44 PM UTC, comment #16:

octave:1> get (0, "screenpixelsperinch")
ans = 95.971

This is ~6 years old computer -- nothing special...


Dmitri A. Sergatskov <dasergatskov>
Sat 18 Nov 2017 06:56:18 PM UTC, comment #15:

@Dmitri: thanks for testing

  • pdfcrop should not go through ghostscript I agree, it is on the TODO list
  • I'll also look into the misplaced glyphs
  • You may not have noticed but the bounding box of the pdf is much too large. What does the following return on your computer?

get (0, "screenpixelsperinch")

Pantxo Diribarne <pantxo>
Project Member
Sat 18 Nov 2017 05:30:08 AM UTC, comment #14:

Attached are inkscape converted files

Inkscape 0.92.2


(file #42422, file #42423)

Dmitri A. Sergatskov <dasergatskov>
Sat 18 Nov 2017 05:27:24 AM UTC, comment #13:

The attached are results of

OK, pdfcrop now works. Both pdf andf pdfcrop file though
seem to be touched by ghostscript (I thought one suppose to go
svg to pdf directly). I also attached the conversion fo the svg into pdf and png by inkscape.

The kerning on the fonts looks wrong (look for space between "b" and "r" in the "sombrero" title).
All pdfs have antialiasing artifacts in the figure.
(The inkscape produced png has also artifacts.)

The fonts seem to be correct.


(file #42419, file #42420, file #42421)

Dmitri A. Sergatskov <dasergatskov>
Fri 17 Nov 2017 10:11:20 AM UTC, comment #12:

Sorry, here is an updated version of the patch with a change log and the bug in comment #11 fixed.

(file #42414)

Pantxo Diribarne <pantxo>
Project Member
Fri 17 Nov 2017 06:35:03 AM UTC, comment #11:

(there is no file "ts1_crop.pdf")

Though the fonts in pdf file are correct.


Dmitri A. Sergatskov <dasergatskov>
Thu 16 Nov 2017 02:03:00 PM UTC, comment #10:

@Rik: I attached an updated version of the conversion tool together with a patch that makes the necessary changes to the print scripts.

Now I have two requests:

  • Could some of you test this intermediate version. The steps to be able to use it are the following:
    • unzip svgvert.zip to "somepath"
    • build the converter
    • apply the patch to octave
    • run as follows from Octave:
  • The patch is currently written to locate the binary either using OCTAVE_SVGCONVERT environment variable or in octave bindir. Don't know if the latter is the best place to install this tool but in any event I don't even know how to build/install the tool with our build environement, so any pointer would be very welcome.

(file #42410, file #42411)

Pantxo Diribarne <pantxo>
Project Member
Thu 09 Nov 2017 04:45:28 PM UTC, comment #9:

@Pantxo: I didn't see any negative responses to your approach on the Octave Maintainer's list. I think you should go forward with the Qt-based conversion tool.

Rik <rik5>
Project Administrator
Mon 30 Oct 2017 10:14:02 AM UTC, comment #8:

@Rik: the raster outputs of the qt converter are often not as good as the ghostscript version (there are blank pixels when drawing tesselated polygons, in 3D scenes mostly). So my first idea would be to continue using ghostscript but for converting pdf2other instead of eps3other (I checked and it works very well). This means an additional conversion stage in most cases (svg->pdf->ghostscript instead of eps->ghostscript).

@Michael: I attached a reproduction of a figure from the japanese Wikipedia page about Japan (https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC) and the script that was used to produce the figure. As you can see tesselation lines have disappeared in bars (due to polygon reconstruction) and Japanese fonts are rendered even if you don't have them installed on your computer (the fonts are embedded).

(file #42299, file #42300)

Pantxo Diribarne <pantxo>
Project Member
Mon 30 Oct 2017 09:53:27 AM UTC, comment #7:

One negative of the current flow is that it makes the
histogram figure in the Manual look very ugly and
wrong due to extraneous diagonal lines through it.
Direct use of print(h, xxx.pdf) produces correct results.

Michael Godfrey <godfrey>
Project Member
Mon 30 Oct 2017 03:57:35 AM UTC, comment #6:

@Pantxo: Why don't you outline your solution on the Octave-Maintainer's list. The current strategy is built around gl2ps to eps, and then using ghostscript to change eps in to whatever format is desired. We could replace this with gl2ps to svg, and then a converter from svg to whatever format is desired. The disadvantage would be that we would need to maintain that tool, and broaden it to reach as many formats as possible. Right now we benefit by relying on the ghostscript project to handle all of that.

Rik <rik5>
Project Administrator
Sun 29 Oct 2017 04:41:04 PM UTC, comment #5:

@Dmitri: yes it is faster and could easily be integrated into Octave without any additional dependency contrary to Inkscape.

Pantxo Diribarne <pantxo>
Project Member
Sun 29 Oct 2017 04:35:58 PM UTC, comment #4:

It is definitely much faster than inkscape (that took few minutes(!)) on my computer.


Dmitri A. Sergatskov <dasergatskov>
Sun 29 Oct 2017 04:22:13 PM UTC, comment #3:

I have written the attached converter (see attached zip) that takes an svg
generated by gl2ps and can write pdf, png, ppm, bmp and jpg outputs.

The converter is currently in the form of a command line Qt based program that
you can compile as follows:

After that, from Octave you can generate the figure you like and have it
converted as follows:

Adding Rik to this report recipients since we have discussed the svg
conversion before.

The only fancy addition of this converter is that it tries to merge contiguous
polygons with the same color to avoid anti-aliasing artifacts. This works well
for 2D figures (see "demo hold 6" converted to pdf, it's beautiful :-)) but
not for 3D figure where depth sorting limits the extent to which the
reconstruction is possible.

(file #42290)

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Oct 2017 03:05:49 PM UTC, comment #2:

Indeed, the only supported fonts are postscript fonts (Times, Helvetica, Courier). Any other choice will lead the print system to fallback to Helvetica.

This has been fixed on the development branch for "svg" output only.

Pantxo Diribarne <pantxo>
Project Member
Sun 08 Oct 2017 02:11:04 PM UTC, comment #1:

I realize that my original description might be a bit confusing. To clarify, there is no way (that I know of) to use a custom font when outputting to an image file using the 'fltk' or 'qt' toolkits. Neither set() not print(..., '-F...') work. When using gnuplot, they both work.

Etienne Dechamps <edechamps>
Sun 08 Oct 2017 02:05:35 PM UTC, original submission:

(Debian Sid, octave 4.2.1-4+b1)

With the 'gnuplot' graphics toolkit, one can choose the font to be used for print() by writing something like the following:

Or, alternatively:

In both cases, the image will be generated using the specified font.

When using the 'fltk' or 'qt' toolkits however, changing the font using set() works for window output, but not for print(), where the default font is always used. That's true at least for PNG and SVG.

In the SVG case it appears the "Helvetica" font is hardcoded in the XML that's being generated. One hacky workaround is to run this command on the SVG file after Octave is done generating it:

Obviously that won't work for PNG or any other raster image type, though.

Etienne Dechamps <edechamps>


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

Attach Files:

Attached Files
file #43366:  hold6_perl.svg added by pantxo (232KiB - image/svg+xml)
file #43367:  hold6_orig.svg added by pantxo (318KiB - image/svg+xml)
file #43363:  mergepoly.pl added by rik5 (3KiB - application/x-perl)
file #43287:  mergepoly.pl added by rik5 (3KiB - application/x-perl)
file #43273:  octave-svgconvert.cc added by rik5 (19KiB - text/x-c++src)
file #43274:  bar.svg added by rik5 (13KiB - image/svg+xml)
file #42933:  tst.pdf added by pantxo (6KiB - application/pdf)
file #42934:  tst2.pdf added by pantxo (284KiB - application/pdf)
file #42426:  ts1_inksc.png added by dasergatskov (58KiB - image/png)
file #42422:  ts1_inks.pdf added by dasergatskov (326KiB - application/pdf)
file #42423:  ts1_inks.png added by dasergatskov (117KiB - image/png)
file #42419:  ts1.pdf added by dasergatskov (285KiB - application/pdf)
file #42420:  ts1.png added by dasergatskov (66KiB - image/png)
file #42421:  ts1_crop.pdf added by dasergatskov (285KiB - application/pdf)
file #42414:  svgconv3.patch added by pantxo (15KiB - text/x-patch)
file #42410:  svgconv.patch added by pantxo (12KiB - text/x-patch)
file #42411:  svgconvert.zip added by pantxo (5KiB - application/zip)
file #42299:  toto.pdf added by pantxo (17KiB - application/pdf)
file #42300:  jap.m added by pantxo (2KiB - text/x-objcsrc)
file #42290:  standalone.zip added by pantxo (4KiB - application/zip)


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-19 pantxo Attached File- => Added hold6_perl.svg, #43366
        Attached File- => Added hold6_orig.svg, #43367
    2018-02-19 rik5 Attached File- => Added mergepoly.pl, #43363
    2018-02-14 rik5 Attached File- => Added mergepoly.pl, #43287
    2018-02-13 rik5 Attached File- => Added octave-svgconvert.cc, #43273
        Attached File- => Added bar.svg, #43274
        Release4.2.1 => dev
    2018-01-17 pantxo Attached File- => Added tst.pdf, #42933
        Attached File- => Added tst2.pdf, #42934
    2017-11-18 dasergatskov Attached File- => Added ts1_crop_okular.png, #42425
        Attached File- => Added ts1_inksc.png, #42426
    2017-11-18 dasergatskov Attached File- => Added ts1_inks.pdf, #42422
        Attached File- => Added ts1_inks.png, #42423
    2017-11-18 dasergatskov Attached File- => Added ts1.pdf, #42419
        Attached File- => Added ts1.png, #42420
        Attached File- => Added ts1_crop.pdf, #42421
    2017-11-17 pantxo Attached File- => Added svgconv3.patch, #42414
    2017-11-16 pantxo StatusConfirmed => In Progress
    2017-11-16 pantxo Attached File- => Added svgconv.patch, #42410
        Attached File- => Added svgconvert.zip, #42411
    2017-10-30 pantxo Attached File- => Added toto.pdf, #42299
        Attached File- => Added jap.m, #42300
    2017-10-29 pantxo Attached File- => Added standalone.zip, #42290
        Carbon-Copy- => Added -email is unavailable-
    2017-10-08 pantxo StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.3