Converting from SVG for some printed output

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Converting from SVG for some printed output

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

Pantxo





OpenGL_Print.ods (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Converting from SVG for some printed output

Rik-4
On 10/30/2017 05:34 AM, [hidden email] 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


Reply | Threaded
Open this post in threaded view
|

Re: Converting from SVG for some printed output

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




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: Converting from SVG for some printed output

Rik-4
In reply to this post by Pantxo
On 11/02/2017 09:00 AM, [hidden email] wrote:
Subject:
Re: Converting from SVG for some printed output
From:
Pantxo [hidden email]
Date:
11/01/2017 01:58 PM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] <MTAwMDAxMS5ub21hZA.1509509700@quikprotect>
In-Reply-To:
<MTAwMDAxMS5ub21hZA.1509509700@quikprotect>
Message-ID:
[hidden email]
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