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:  Patch Submitted 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)

Tue 09 Oct 2018 04:07:20 PM UTC, comment #55:

@jwe: Yes, Rik had already warned me about that but it looks like I had forgotten a few. I attached a new version in which I removed all instances of std::cout except 1 (displaying the help message when one passes the "-h" option). I also fixed a few warnings I had not seen yesterday.

(file #45169)

Pantxo Diribarne <pantxo>
Project Member
Tue 09 Oct 2018 02:51:20 AM UTC, comment #54:

Pantxo: I see a mixture of messages to std::cout and std::cerr. Is that intentional? Some of the messages written to std::cout look like error messages to me.

John W. Eaton <jwe>
Project Administrator
Mon 08 Oct 2018 08:47:43 PM UTC, comment #53:

@Mike: Many thanks, this is exactly what I needed. I just had to add the QtXml module in acinclude.m4 for the compilation to go on. I attached a modified patch for testing.

(file #45166)

Pantxo Diribarne <pantxo>
Project Member
Mon 08 Oct 2018 07:01:28 PM UTC, comment #52:

Integrating octave-svgconvert into the build system should be something like this

This is untested, just based on what I would start with. This is a completely standalone program that doesn't use any Octave headers or libraries, right?

This will install the program octave_config_info("archlibdir"), which is where octave-gui is installed. I think that directory is added to $PATH when Octave starts, so it should be callable by name. When using ./run-octave, when it hasn't been installed yet, something may have to be done to the environment to allow the program to be found in the build directory.

Mike Miller <mtmiller>
Project Administrator
Thu 13 Sep 2018 09:16:14 PM UTC, comment #51:

Ok, I attached the mammoth patch. Now I have no clue about how to compile and distribute the converter tool :-).

(file #45004)

Pantxo Diribarne <pantxo>
Project Member
Thu 13 Sep 2018 06:19:46 PM UTC, comment #50:

Sure. Let's make one gigantic patch, apply it, and then clean up.

Rik <rik5>
Project Administrator
Thu 13 Sep 2018 12:43:40 PM UTC, comment #49:

@Rik: Do you want me to integrate octave-svgconvert.cc into the "src" directory and make a single patch. This would avoid having to deal with 2 different files from comment X an Y.

Pantxo Diribarne <pantxo>
Project Member
Thu 13 Sep 2018 12:40:12 PM UTC, comment #48:

I attached a slightly updated version of octave-svgconvert.cc that adds support for italic fonts (forgotten in previous versions).

(file #44998)

Pantxo Diribarne <pantxo>
Project Member
Thu 06 Sep 2018 09:40:01 PM UTC, comment #47:

pdflatexstandalone seems to produce an OK image. Though one needs to tweak the tex file to get subscripts/superscripts and fonts right.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 06 Sep 2018 07:57:17 PM UTC, comment #46:

For me Inkscape is even worse when it comes to dealing with embedded images: colors are preserved but pixels are blurry ... at least with Inkscape 0.92 and the current state of our svg files. See

Yes, the original plot is terrible, but printout are always worse.

Pantxo Diribarne <pantxo>
Project Member
Thu 06 Sep 2018 04:31:59 PM UTC, comment #45:

@Pantxo: I can help convert things in to OCtave's build system. What is the workaround for images within PDF right now? Do we export instead to svg and then have the user convert svg to pdf?

Rik <rik5>
Project Administrator
Tue 04 Sep 2018 06:05:34 PM UTC, comment #44:

I attached an updated patch that implements the non default -svgconvert option, together with the latest version of octave-svgconvert.cc.

If it is admitted that this approach is reasonable then I am pretty much done with what I was able to do alone. I would really need a hand in finalizing the patch and integrating octave-svgconvert.cc into the build system.

(file #44936, file #44937)

Pantxo Diribarne <pantxo>
Project Member
Tue 04 Sep 2018 07:57:48 AM UTC, comment #43:

Ok, so this is a know Qt bug (https://bugreports.qt.io/browse/QTBUG-54809) which has not received any comments in two years.

@Dmitri: I don't know gnuplot at all and cloning their pdf rendering engine is not an option for me.

Pantxo Diribarne <pantxo>
Project Member
Mon 03 Sep 2018 09:22:29 PM UTC, comment #42:

I also tried the same demo with gnuplot backend (with qt terminal)
and exported to pdf from gnuplot window -- I got what appears to be a correct pdf. (attached t1-gnuplot.pdf).
What does gnuplot do to export to pdf?

Dmitri.
--

(file #44929)

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Sep 2018 09:14:35 PM UTC, comment #41:

Thanks! I guess I got the same problem with Qt 5.10.1.
BTW the file is still passed through ghostscript:

pdfinfo toto.pdf
Title:
Creator:
Producer: GPL Ghostscript 9.22
CreationDate: Mon Sep 3 15:36:57 2018 CDT
ModDate: Mon Sep 3 15:36:57 2018 CDT
Tagged: no

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Sep 2018 09:00:49 PM UTC, comment #40:

Attached.

(file #44928)

Pantxo Diribarne <pantxo>
Project Member
Mon 03 Sep 2018 08:49:04 PM UTC, comment #39:

Can you upload toto.pdf?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 03 Sep 2018 08:34:45 PM UTC, comment #38:

I uploaded an updated version of the qt converter in which I removed all instances of qDebug and printf and favored std::cerr, I removed the ability to convert to raster formats since we don't use it and I reworked a few minor things.

Unfortunately I have some bad news, there is something very wrong when printing images: neighbor pixels colors get somehow mixed. This is mostly visible in "uncorrelated" (e.g. random) images:

This is most probably a bug in Qt's QPrinter painting device since painting to a QImage works perfectly. I reported a simplified example of the misbehavior on Qt's forum but got no answer (https://forum.qt.io/topic/94230/printing-qimage-to-pdf)

This looks like a show stopper for svg conversion being the default. Thoughts ?
Could I add a "-svgconvert" flag to allow the use of svg conversion when images don't come into play?

(file #44927)

Pantxo Diribarne <pantxo>
Project Member
Wed 29 Aug 2018 03:21:21 AM UTC, comment #37:

I'm using the latest file. The help text reverted to

I had done some clean up of the C++ code and uploaded my version of octave-svgconvert.cc as file #43273. In that version the help text has "octave-svgconvert" in the help text.

@Pantxo: You might want to merge file #43273 and file #44813 before proceeding with your cleanup.

Rik <rik5>
Project Administrator
Wed 29 Aug 2018 12:48:39 AM UTC, comment #36:

Rik -- oyu are using the old converter (qt-svg-convert) rather than a new converter (octave-svgconvert) from files 42411+44813

Saving to svg works for me.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 29 Aug 2018 12:08:08 AM UTC, comment #35:

Never mind -- I tried to apply it on stable. Works fine on dev.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 28 Aug 2018 11:57:31 PM UTC, comment #34:

svgconv4.patch does not apply cleanly with a recent snapshot:

patching file scripts/plot/util/print.m
Hunk #3 FAILED at 134.
Hunk #6 FAILED at 201.
Hunk #7 succeeded at 207 with fuzz 1 (offset -4 lines).
Hunk #8 succeeded at 222 (offset -4 lines).
Hunk #9 succeeded at 345 (offset -4 lines).
Hunk #10 succeeded at 397 (offset -4 lines).
Hunk #11 succeeded at 585 (offset -4 lines).
Hunk #12 succeeded at 654 (offset -4 lines).
Hunk #13 succeeded at 891 (offset -4 lines).
2 out of 13 hunks FAILED -- saving rejects to file scripts/plot/util/print.m.rej
patching file scripts/plot/util/private/__opengl_print__.m
patching file scripts/plot/util/private/__print_parse_opts__.m
Hunk #3 FAILED at 217.
Hunk #4 succeeded at 223 (offset -2 lines).
Hunk #5 succeeded at 238 (offset -2 lines).
Hunk #6 succeeded at 385 (offset -3 lines).
Hunk #7 succeeded at 470 (offset -3 lines).
Hunk #8 succeeded at 481 (offset -3 lines).
Hunk #9 succeeded at 507 (offset -3 lines).
1 out of 9 hunks FAILED -- saving rejects to file scripts/plot/util/private/__print_parse_opts__.m.rej

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 28 Aug 2018 11:18:57 PM UTC, comment #33:

Dang it. I wrote a big long e-mail after testing the patch, but it got truncated.

The short version is that this is a big improvement and you should go ahead and finalize this patch for inclusion in Octave.

One thing to note is that svg conversion was only available if I produce the svg in a prior version of Octave and then used octave-svgconvert on the command line. Trying to print directly to svg results in an error.

Rik <rik5>
Project Administrator
Tue 28 Aug 2018 11:08:33 PM UTC, comment #32:

@Pantxo: Certainly this seems like a big improvement and I think it should go forward. Regarding the issues you mentioned:

  • Polygon reconstruction is now implemented so that distant polygons won't be accidentally merged (disabling anti-aliasing in Okular should not show spurious lines anymore)

The is mostly the case. I always use this test case for 2-D polygon reconstruction.

Rik <rik5>
Project Administrator
Mon 20 Aug 2018 08:58:59 PM UTC, comment #31:

The kerning of the font appears to be the issue with "Roboto" font
handling (I am not even sure what component is at fault here).
E.g. "Noto" looks fine.

Position of the figure in pdf has changes and I do not see bounding box any more, so not sure if it fixed, or just changed
(I attached the file).

Dmitri.
--

(file #44818)

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Aug 2018 02:51:44 PM UTC, comment #30:

<<< It has always been the case. This is a special case where the pdf figure is generated by Latex, not Octave. >>>

I guess this can be fixed if we use xetex instead of pdflatex.
But perhaps this is the subject of another bug report.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Aug 2018 12:56:58 PM UTC, comment #29:

@Dmitri:

>> in extended.pdf the fonts are now Computer-Modern rather than FreeSans.


It has always been the case. This is a special case where the pdf figure is generated by Latex, not Octave. You can look at the html version of the manual (section 15.2.9) or directly at extended.png and you should see that it is correctly generated with freesans font by Octave.
BTW this section of the manual should be reworded so that :

  • it is clear that the html and pdf versions don't use the same figure generation pipeline.
  • erroneous statements about the "latex" renderer are removed
Pantxo Diribarne <pantxo>
Project Member
Mon 20 Aug 2018 12:26:30 PM UTC, comment #28:

Looks great!

I rebuilt doc/ with this patch and all figures look quite nice.
The only problem I found that in extended.pdf the fonts are now
Computer-Modern rather than FreeSans.
I will play more with this later.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 20 Aug 2018 08:23:48 AM UTC, comment #27:

I attached a "work in progress" version of both the patch for Octave and the converter utility. Those address some of the comments that have been brought by Dmitri and Rik:

  • Polygon reconstruction is now implemented so that distant polygons won't be accidentally merged (disabling anti-aliasing in Okular should not show spurious lines anymore)
  • SVG format is now also processed by the converter and one can inspect the file in Inkscape

The remaining issues are:

  • The converter has to be cleaned up to remove raster output code (unused in Octave since we convert PDF to raster for better looking results) and c++ify/cleanup the coding in general. I'll do that in a further step, if/when the integration of this patch is accepted.
  • 3D scenes are not much better after conversion. I think there is nothing we can do about that with this approach.
  • "pdfcrop" option goes through the ghostscript pipeline: I didn't handle this because it may be useful to have the pdf processed by ghostscipt for implementing the "tight" option
  • Some misplaced characters in the PDF output: I have never faced this issue and can't debug. @Dmitri: can you confirm that you still experience this issue?
  • Wrong bounding box: I have never faced this issue either. @Dmitri: can you confirm that you still experience this issue?

The steps for building/patching/testing are the same as in comment #10.

(file #44812, file #44813)

Pantxo Diribarne <pantxo>
Project Member
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.

Dmitri.

(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.
--

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

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

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

Dmitri.

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

Dmitri.
--

(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.

Dmitri.

(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.
--

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.
--

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:
   
   
Comment:
   

Attached Files
file #45169:  svgconv7.patch added by pantxo (44KiB - text/x-patch)
file #45166:  svgconv6.patch added by pantxo (44KiB - text/x-patch)
file #45004:  svgconv5.patch added by pantxo (42KiB - text/x-patch)
file #44998:  octave-svgconvert.cc added by pantxo (24KiB - text/x-c++src)
file #44936:  octave-svgconvert.cc added by pantxo (24KiB - text/x-c++src)
file #44937:  svgconv5.patch added by pantxo (17KiB - text/x-patch)
file #44929:  t1-gnuplot.pdf added by dasergatskov (116KiB - application/pdf)
file #44928:  toto.pdf added by pantxo (36KiB - application/pdf)
file #44927:  octave-svgconvert.cc added by pantxo (24KiB - text/x-c++src)
file #44818:  ts1_20180820.pdf added by dasergatskov (268KiB - application/pdf)
file #44812:  svgconv4.patch added by pantxo (16KiB - text/x-patch)
file #44813:  octave-svgconvert.cc added by pantxo (25KiB - text/x-c++src)
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 jwe (Posted a comment)
  • -email is unavailable- added by johasixt
  • -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-10-09 pantxo Attached File- => Added svgconv7.patch, #45169
    2018-10-08 pantxo Attached File- => Added svgconv6.patch, #45166
        StatusIn Progress => Patch Submitted
    2018-10-08 johasixt Carbon-Copy- => Added johasixt
    2018-09-13 pantxo Attached File- => Added svgconv5.patch, #45004
    2018-09-13 pantxo Attached File- => Added octave-svgconvert.cc, #44998
    2018-09-04 pantxo Attached File- => Added octave-svgconvert.cc, #44936
        Attached File- => Added svgconv5.patch, #44937
    2018-09-03 dasergatskov Attached File- => Added t1-gnuplot.pdf, #44929
    2018-09-03 pantxo Attached File- => Added toto.pdf, #44928
    2018-09-03 pantxo Attached File- => Added octave-svgconvert.cc, #44927
    2018-08-20 dasergatskov Attached File- => Added ts1_20180820.pdf, #44818
    2018-08-20 pantxo Attached File- => Added svgconv4.patch, #44812
        Attached File- => Added octave-svgconvert.cc, #44813
    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

    Back to the top


    Powered by Savane 3.3