[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
>10.000
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
ghostscript.
Xpdf's pdftops does a better job.
/Andreas
More information about the Printing-summit
mailing list