Sat 18 Nov 2017 07:06:51 PM UTC, comment #18:
Attached screenshots.
Dmitri.
(file #42425, file #42426)
|
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.
--
|
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.
|
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")
|
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)
|
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)
|
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)
|
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.
--
|
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)
|
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.
|
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)
|
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.
|
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.
|
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.
|
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.
--
|
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)
|
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.
|
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.
|
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.
|