Now that I have a recent enough version of Qt, I was able to confirm that the bug with lossy encoding of images in PDF output (see comment #57) could be avoided using the new option provided for QPainter. I pushed a patch here:

https://hg.savannah.gnu.org/hgweb/octave/rev/55415fa6a20f

For anyone willing to test, without the above change or with Qt < 5.13, the following image should render differently onscreen and in PDF output:

figure;
imshow (rand (5, 5, 3))
print -svgconvert -dpdfcrop toto.pdf

@Panxto:
Where I wrote that the executable exists, I failed to check if the path to the font exists; it doesn't. Your newer patch fixes that, and with it I get no more error messages. So it looks like this bug is fixed.

Yes it works. I confused myself with

fullfile (octave_config_info ("datadir"), "font", "FreeSans.otf")

line.

Sorry about that.

Dmitri.

That seems to be correct:

octave:1> demo getframe 2
getframe example 2:
 clf reset;
 contourf (rand (5));
 frame = getframe (gcf ());
 imshow (frame.cdata);
 set (gca, "position", [0 0 1 1]);

octave:2> print("t1.svg")
cmd = /usr/local/libexec/octave/5.0.0/exec/x86_64-pc-linux-gnu/octave-svgconvert - %s 95.97 /usr/local/share/octave/5.0.0/fonts/FreeSans.otf 1 %s

Dmitri.

The patch did not change anything:

octave:1> fullfile (_octave_config_info_ ("datadir"), "font", "FreeSans.otf")
ans = /usr/local/share/font/FreeSans.otf

octave:2> type print.m
<......>

 if (isempty (opts.svgconvert_binary))
    warning ("octave:print:nosvgconvert", ...
             ["print.m: unale to find octave-svgconvert, ", ...
              "falling back to eps convertion"]);
  else
    fontdir = getenv ("OCTAVE_FONTS_DIR");
   
    if (isempty (fontdir))
      fontdir = _octave_config_info_ ("octfontsdir");
    endif
   
    cmd = sprintf ("%s - %%s %3.2f %s %d %%s", opts.svgconvert_binary, ...
                   get (0, "screenpixelsperinch"), ...
                   fullfile (fontdir, "FreeSans.otf"), 1);

    if (opts.debug)
      fprintf ("svgconvert command: '%s'\n", cmd);
    endif
  endif

endfunction

@Philip, Dmitri: Thanks, so indeed the path that is passed to octave-svgconvert is not right. I attached a patch that should do a better job, but again I didn't really test it.

(file #45410)

@Panxto:
In debug mode:

debug> fullfile (__octave_config_info__ ("datadir"), "font", "FreeSans.otf")
ans = L:\philip\devel\octdev\mxe\mxe64b_20180926\dist\octave\mingw64\share\font\FreeSans.otf
debug>
debug> sprintf ("%s - %%s %3.2f %s %d %%s", opts.svgconvert_binary, ...
 get (0, "screenpixelsperinch"), def_font, 1)
ans = L:\philip\devel\octdev\mxe\mxe64b_20180926\dist\octave\mingw64\libexec\octave\5.0.0\exec\x86_64-w64-mingw32\octave-svgconvert.exe - %s 72.05 L:\philip\devel\octdev\mxe\mxe64b_20180926\dist\octave\mingw64\share\font\FreeSans.otf 1 %s
debug>
debug> opts.debug
ans = 0

so it looks like this part works in Windows. The octave-svgconvert binary is in the indicated location.

Continuing debug-stepping, the "Unable to add default font to database" comes from a call to drawnow() in ___open_gl_print_() at L.193. (but you might know that).

Anything else I can try?

A testcase as requested by Panxto:

demo getframe 2
print("t1.svg")

(from bug #52303)

gives:

>> :
>> print("t1d.svg")
Unable to add default font to database

... yet the printed figure file does have axis ticks.

Maybe you should just check in the changeset.  I don't know if anyone is following this and building with MXE.  At worst, we can simply disable the '-svgconvert' option for Windows until it is worked out.

I'd like to push this change, but before it would be useful to know if it works on Windows.

Can someone here with an mxe build test it?

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.

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

--- a/src/module.mk
+++ b/src/module.mk
@@ -49,6 +49,11 @@ if AMCOND_BUILD_QT_GUI
   OCTAVE_INTERPRETER_TARGETS += %reldir%/octave-gui$(EXEEXT)
 endif

+if AMCOND_BUILD_QT_GUI
+  archlib_PROGRAMS += %reldir%/octave-svgconvert
+  OCTAVE_INTERPRETER_TARGETS += %reldir%/octave-svgconvert$(EXEEXT)
+endif
+
 OCTAVE_CORE_LIBS = \
   libinterp/liboctinterp.la \
   liboctave/liboctave.la \
@@ -115,6 +120,14 @@ endif
   $(OCTAVE_GUI_LINK_OPTS) \
   $(WARN_LDFLAGS)

+%canon_reldir%_octave_svgconvert_SOURCES = %reldir%/octave-svgconvert.cc
+
+%canon_reldir%_octave_svgconvert_CPPFLAGS = $(QT_CPPFLAGS)
+
+%canon_reldir%_octave_svgconvert_LDADD = $(QT_LIBS)
+
+%canon_reldir%_octave_svgconvert_LDFLAGS = $(QT_LDFLAGS)
+
 %canon_reldir%_mkoctfile_SOURCES =

 nodist_%canon_reldir%_mkoctfile_SOURCES = %reldir%/mkoctfile.cc

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.

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

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


(file #44998)

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

demo area 1
image ("xdata", [2 4], "ydata", [.4 .8], "cdata", rand (20, 20, 3))
title ("Température du glaçon", "fontname", "LiberationSerif")

## Wrong pixel colors with Qt
print -svgconvert svg2pdf_qt.pdf
open svg2pdf_qt.pdf

## Blurry/antialiased images with Inkscape
print -svgconvert toto.svg
system ("inkscape -z -f=toto.svg --export-pdf svg2pdf_ink.pdf")
open svg2pdf_ink.pdf

## Antialiasing for patches and poor text support
print eps2pdf.pdf
open eps2pdf.pdf

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

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)

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)

Attached.


(file #44928)

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:

demo imshow 7
print -dsvg toto.svg
print -dpdfcrop toto.pdf

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)

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.

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

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

demo area 1
print tst.pdf
open tst.pdf
-verbatim

The results are excellent.  For a very complex scene, I tried

+verbatim+
demo hold 6
print tst.pdf
open tst.pdf

This also works better than before.

To test text using a strange font I tried

close all
ht = text (0.4, 0.05, "Hello World", "fontname", "comic sans ms", "fontsize", 20);
print tst.pdf
open tst.pdf

The correct font is used and the spacing seems to match what is displayed onscreen.

• SVG format is now also processed by the converter and one can inspect the file in Inkscape

This doesn't work for me yet.  I tried

demo area 1
print -dsvg tst.svg
Unhandled output file format svg
Usage:
        qt-svg-convert infile fmt dpi font reconstruct outfile

Convert svg file to pdf, or raster file formats. All arguments are mandatory:
* infile: input svg file or "-"to indicate that the input svg file should be read from stdin
* fmt: format of the output file. May be one of pdf, bmp, jpg, png or ppm
* dpi: device dependent resolution in screen pixel per inch
* font: specify a file name for the default FreeSans font
* reconstruct: specify wether to reconstruct polygons (0 or 1)
* outfile: output file name

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.

I think this patch is acceptable and you can start to make the code beautiful.

• 3D scenes are not much better after conversion. I think there is nothing we can do about that with this approach.

They may not be much better, but they are improved.  The number of polygons, even in 3-D scenes, is reduced.  I used this test code

sombrero
print tst.pdf

• "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

I think this is okay for now.

• 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?

I think this is working now if I read Dmitri's comments correctly.

• Wrong bounding box: I have never faced this issue either. @Dmitri: can you confirm that you still experience this issue?

I think this is working now.

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

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

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

close all
demo hold 6
print hold6_orig.svg
system "perl mergepoly.pl hold6_orig.svg > hold6_perl.svg"

(file #43366, file #43367)

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

Sample code:

demo area 1
print tst.svg
exit

And in the shell

mergepoly.pl tst.svg > tst2.svg
inkscape tst2.svg

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

Attached screenshots.

Dmitri.

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

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

Dmitri.

Attached are inkscape converted files

inkscape ts1.svg --export-pdf ts1_inks.pdf
inkscape ts1.svg --export-png ts1_inks.png

Inkscape 0.92.2

Dmitri.
--


(file #42422,

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

(file #42414)

@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

cd somepath
qmake
make

** apply the patch to octave
** run as follows from Octave:

setenv OCTAVE_SVGCONVERT somepath/octave-svgconvert
plot (1:10) # or whatever plot you like
print somfile.pdf
print -dpdfcrop somefilecropped.pdf
print somefile.png # or any raster format

• 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)

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

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

Dmitri.
--

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.

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

set(gcf(), 'defaultaxesfontname', 'DejaVuSansMono');
set(gcf(), 'defaulttextfontname', 'DejaVuSansMono');

Or, alternatively:

print('image.png', '-dpng', '-FDejaVuSansMono');

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:

$ sed -i 's/font-family="Helvetica"/font-family="DejaVuSansMono"/g' image.svg

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