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

 
 

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

Submitter:  Etienne Dechamps <edechamps>
Submitted:  Sun 08 Oct 2017 02:05:35 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

Mon 29 Aug 2022 02:59:02 PM UTC, comment #74: 

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


Pantxo Diribarne <pantxo>
Group Member
Mon 12 Nov 2018 09:21:16 PM UTC, comment #73: 

Thanks, I pushed this modified cset:

http://hg.savannah.gnu.org/hgweb/octave/rev/4407b315339d

It also prevents octave-svgconvert from unnecessarily loading the default fault for SVG format.

Pantxo Diribarne <pantxo>
Group Member
Mon 12 Nov 2018 08:08:45 PM UTC, comment #72: 

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

Philip Nienhuis <philipnienhuis>
Group Member
Mon 12 Nov 2018 06:52:12 PM UTC, comment #71: 


octave:1> plot (1:10);
octave:2> print -svgconvert /tmp/toto.pdf
octave:3> system ("pdffonts /tmp/toto.pdf")
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
OZUHMJ+FreeSans                      CID TrueType      Identity-H       yes yes yes     10  0
ans = 0


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Nov 2018 06:30:57 PM UTC, comment #70: 

Yes it works. I confused myself with

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

line.

Sorry about that.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Nov 2018 04:43:21 PM UTC, comment #69: 

@Dmitri: Thanks, so does the patch actually work (did the warning disappear)? For example, does the following simple example work?


plot (1:10);
print -svgconvert /tmp/toto.pdf
system ("pdffonts /tmp/toto.pdf")


If it works, pdffonts should show you that FreeSans, which is not on your system, is embedded (and the PDF is portable).

Pantxo Diribarne <pantxo>
Group Member
Mon 12 Nov 2018 02:52:17 PM UTC, comment #68: 

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.

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Nov 2018 02:17:39 PM UTC, comment #67: 

@Dmitri: I think I'd better learn how to safely remove a font from my system (ubuntu) or I'll bother you all with bad untested patches.

Anyway, the patch I provided doesn't change the value of "_octave_config_info_ ("datadir")" but it doesn't use this anymore. This construct is replaced by OCTAVE_FONTS_DIR (if it exists) or by "_octave_config_info_ ("octfontsdir")".

Can you remove the semicolon after "cmd = sprintf ..." and see if the path of the font file is now correct? You should see "your_source_dir/etc/fonts/FreeSans.otf", if running run-octave, or "your_prefix/share/octave/5.0.0/fonts/FreeSans.otf", if running from an installed binary.

Pantxo Diribarne <pantxo>
Group Member
Mon 12 Nov 2018 01:15:54 AM UTC, comment #66: 

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

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Nov 2018 12:55:39 AM UTC, comment #65: 

Oups missing semicolon.

(file #45411)

Pantxo Diribarne <pantxo>
Group Member
Mon 12 Nov 2018 12:54:41 AM UTC, comment #64: 

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

Pantxo Diribarne <pantxo>
Group Member
Sun 11 Nov 2018 11:50:44 PM UTC, comment #63: 

I get the same error message on linux if I remove FreeSans from the system.

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

But the fonts aren't there:

find /usr/local -name "Free*"
/usr/local/share/octave/5.0.0/fonts/FreeSans.otf
/usr/local/share/octave/5.0.0/fonts/FreeSansOblique.otf
/usr/local/share/octave/5.0.0/fonts/FreeSansBoldOblique.otf
/usr/local/share/octave/5.0.0/fonts/FreeSansBold.otf

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 11 Nov 2018 09:57:31 PM UTC, comment #62: 

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

Philip Nienhuis <philipnienhuis>
Group Member
Sat 10 Nov 2018 08:17:23 PM UTC, comment #61: 

@Philip: Thanks for testing. This warning should never happen when printing to svg since for this format we don't need the font file at all. I'll fix this.
Anyway, you'll have the same problem of not being able to embed the right default font in PFD files.

Since my system has FreeSans installed by default, I did not have a chance to test Qt font registering my self.

Could you look at the "cmd" variable, around line 1004 in print.m? It should contain the path of FreeSans.otf, the default font file that is distributed along with Octave. Do you see something suspicious?

Pantxo Diribarne <pantxo>
Group Member
Sat 10 Nov 2018 03:29:49 PM UTC, comment #60: 

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.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 04 Nov 2018 08:33:54 PM UTC, comment #59: 

Ok, so I pushed the patch here:

http://hg.savannah.gnu.org/hgweb/octave/rev/98d7a111786a

Marking the report "Ready for test"



Pantxo Diribarne <pantxo>
Group Member
Fri 02 Nov 2018 07:35:39 PM UTC, comment #58: 

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.

Rik <rik5>
Group administrator
Thu 01 Nov 2018 02:34:13 PM UTC, comment #57: 

BTW, the Qt bug that prevents images from being printed correctly has been fixes (https://bugreports.qt.io/browse/QTBUG-54809) but this change will only appear in Qt 5.13.

Pantxo Diribarne <pantxo>
Group Member
Thu 01 Nov 2018 02:32:14 PM UTC, comment #56: 

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 Diribarne <pantxo>
Group Member
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>
Group 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>
Group 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>
Group Member
Mon 08 Oct 2018 07:01:28 PM UTC, comment #52: 

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.

Mike Miller <mtmiller>
Group Member
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>
Group 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>
Group 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>
Group 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>
Group 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


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.

Pantxo Diribarne <pantxo>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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:


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)

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

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


int main(int argc, char *argv[])
{
  const char *help =
"Usage:\n\
\tqt-svg-convert infile fmt dpi font reconstruct outfile\n\n\
Convert svg file to pdf, or raster file formats. All arguments are mandatory:\n\
* infile: input svg file or \"-\"to indicate that the input svg file should be \
read from stdin\n\
* fmt: format of the output file. May be one of pdf, svg, bmp, jpg, png or ppm\n\
* dpi: device dependent resolution in screen pixel per inch\n\
* font: specify a file name for the default FreeSans font\n\
* reconstruct: specify wether to reconstruct polygons (0 or 1)\n\
* outfile: output file name\n";


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


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



Rik <rik5>
Group 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.


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.



Rik <rik5>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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:


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




(file #43366, file #43367)

Pantxo Diribarne <pantxo>
Group 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>
Group 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:


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


plot (rand (5,3), '.-', 'markersize', 16)
print tst.pdf


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


sombrero
set (gcf, 'papersize', [10, 5.7], 'paperposition', [ 0 0 10 5.7])
print tst2.svg
print tst2.pdf


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>
Group administrator
Sat 18 Nov 2017 07:06:51 PM UTC, comment #18: 

Attached screenshots.

Dmitri.



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>
Group Member
Sat 18 Nov 2017 05:30:08 AM UTC, comment #14: 

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,

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

The attached are results of


set(0, 'DefaultAxesFontName', 'Roboto');
set(0, 'DefaultTextFontName', 'Roboto');
setenv("OCTAVE_SVGCONVERT", "/usr/local/bin/octave-svgconvert")
sombrero
title("Sombrero")
print("ts1.svg")
print("ts1.pdf")
print("ts1_crop.pdf", "-dpdfcrop")
print("ts1.png")



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 #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>
Group Member
Fri 17 Nov 2017 06:35:03 AM UTC, comment #11: 




octave:1> setenv("OCTAVE_SVGCONVERT", "/usr/local/bin/octave-svgconvert")
octave:2> sombrero
octave:3> print("ts1.svg")
octave:4> print("ts1.pdf")
octave:5> print("ts1_crop.pdf", "-dpdfcrop")
error: suffixes(56): out of bound 55
error: called from
    __print_parse_opts__ at line 262 column 18
    print at line 318 column 8
octave:5> print("ts1.png")
octave:6>
[dima@i7 gcc_def]$ pdfinfo ts1.pdf
Title:
Creator:
Producer:       GPL Ghostscript 9.22
CreationDate:   Fri Nov 17 00:26:02 2017 CST
ModDate:        Fri Nov 17 00:26:02 2017 CST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      612 x 792 pts (letter)
Page rot:       0
File size:      288133 bytes
Optimized:      no
PDF version:    1.5

(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


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)

Pantxo Diribarne <pantxo>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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:


qmake qt-svg-convert.pro
make


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


demo text 2
ch = findobj (gca, "type", "text");
set (ch, "fontname", "DejaVuSansMono");
infile = "toto.svg";
outfile = "toto.pdf"
fmt = "pdf";
dpi = get (0, "screenpixelsperinch");

print (infile);
cmd = sprintf ("./qt-svg-convert %s %s %3.2f %s",
               infile, fmt, dpi, outfile);
system (cmd)


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


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.

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 #45411:  defaultfont.patch added by pantxo (1KiB - text/x-patch)
file #45410:  defaultfont.patch added by pantxo (1KiB - text/x-patch)
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)
  •  

    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-12-13 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-11-12 pantxo Attached File- Added defaultfont.patch, #45411
    2018-11-12 pantxo Attached File- Added defaultfont.patch, #45410
    2018-11-04 pantxo StatusPatch Submitted Ready For Test
    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

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code