octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Converting from SVG for some printed output


From: Rik
Subject: Re: Converting from SVG for some printed output
Date: Thu, 2 Nov 2017 17:10:10 -0700

On 11/02/2017 09:00 AM, address@hidden wrote:
Subject:
Re: Converting from SVG for some printed output
From:
Pantxo <address@hidden>
Date:
11/01/2017 01:58 PM
To:
address@hidden
List-Post:
<mailto:address@hidden>
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
References:
<address@hidden> <address@hidden>
In-Reply-To:
<address@hidden>
Message-ID:
<address@hidden>
Content-Type:
text/plain; charset=UTF-8
Message:
3

Rik-4 wrote
On 10/30/2017 05:34 AM, 
octave-maintainers-request@
 wrote:
Hi,

Our OpenGL printing work flow is currently mostly based on the conversion
of EPS files generated by GL2PS into other formats through the use of
Ghostscript (for raster formats and pdf) and pstoedit/fig2dev for other
vector formats such as xfig, emf ... The only exceptions are
pdflatex(standalone), which directly makes use of GL2PS native pdf
format, and svg. See attached file for a summary.

This conversion chain inherits all the limitations of the original EPS
file:

* Only 127 ascii characters are supported

* Only the 14 base fonts can be used

* Transparency is not handled at all

On the other hand we have a pretty full-featured SVG output. I thus wrote
a Qt based program that converts SVG from GL2PS (it is in no way a
general purpose svg converter, see http://savannah.gnu.org/bugs/?52193)
to PDF, and I would like to know if there is interest in adding this
program to Octave?

My idea would be to replace the EPS->Ghostscript chain to
SVG->PDF->Ghostscript for the following final formats: any Ghostscript
raster format (jpg, png, pbm, ...) and pdf (go through Ghostscript to
setup the surrounding page).  For "pdfwrite" (no surrounding page) we
would simply use SVG->PDF conversion.

This seems like a good idea to me.  I like the fact that it might get rid
of the tesselation lines in the pdf output as well, and it would handle
transparency. 

--Rik
That is an important point I forgot to mention. The converter also tries to
merge 
triangles to form larger polygons when possible. In practice it works very
well but 
only for 2D figures (probably worth more than 99% of the use case (100% in
my case)). 
For 3D figures, there is a noticeable improvement but surfaces are still
ugly.

Note that there is a much better candidate for solving this tesselation
lines issue in 3D which is 
using the native PDF format (see [1]), but this format has a number of
bugs** 
and it does not solve our problem (mine at least) with text handling.

Pantxo

[1] https://savannah.gnu.org/bugs/?45494

** - Solved: text alignment (dev), image scaling (latest release)
     - Unsolved I know about: line transparency not supported, not all pdf
renderers support the way gl2ps writes transparent polygons, lit surfaces
sometimes rendered with "holes". 

I'm a fan of getting something written quickly, and then iterating to improve it.  This seems like a useful idea so I think you should go ahead and work on checking something in.  We can then find and correct whatever issues remain.

--Rik

reply via email to

[Prev in Thread] Current Thread [Next in Thread]