[Desktop_printing] PS/PDF import, was: Microsoft XPS specification

Andreas Vox avox at scribus.info
Fri Apr 21 17:53:26 PDT 2006

> avox wrote:
>  >>No, Scribus uses a similar approach but not the same code as 
> pstoedit.
>  >>
>  >>The idea is to redefine basic PS operators to write their arguments 
> and
>  >>the
>  >>current graphics state to a temporary file and then interpret that 
> file.
> Is this approach robust?
Not really, but it works quite well. Only other option would be to write
a special driver for ghostscript.

> ...
>  >>The current internals of Scribus
>  >>make editing
>  >>thousands of vector paths very slow and resource intensive.
>  >
> you mean more vector paths than what really needed or used? Because 
> often
> EPS graphics produced by programs (think for instance to
> EPS output from math programs like matlab, mathematica, etc.),
> have plenty of vector paths overlapping each other which might
> be useless, but they are in the PS code.

No, it's just that a text with 10.000 characters becomes a group of 
vector objects.

> What I've also not yet seem (maybe exists) is a PS optimizer
> which simplify/removes all the hidden and overlapping lines/paths 
> (think for
> instance to what is currently done with FontForge).

I don't think that's worth the trouble.

> For editing
> I think this could be a nice feature (well apart defining an elliptical
> pen bezier stroke in term of an outline closed path [which is very hard
> from math points of view]).

Inkscape might have that kind og pen shape.

> > ... PDF is another story.
> Well, couldn't PDF be converted on EPS on the fly?

We currently don't have a PDF reader but rely on ghostscript for that.
pdf2ps from ghostscript doesn't produce PS which is usable by 
Xpdf's pdftops does a better job.


More information about the Printing-summit mailing list