Subject: Re: On the Road to version 1.0
From: Bryce Nesbitt (bryce@obviously.com)
Date: Tue Dec 25 2001 - 16:23:08 CST
Martin Sevior wrote:
>
> On Fri, 21 Dec 2001, Bryce Nesbitt wrote:
>
> > Leonard Rosenthol wrote:
> > > At 11:48 AM 12/21/2001 -0500, Bryce Nesbitt wrote:
> > > > > But in general, keeping things vector (be it EPS, PDF or SVG)
> > > > > until the last minute is definitely the way to go!
> > > >
> > > >And it's the only way to go if you don't know what your output device is
> > > >yet!
> > >
> > > Why wouldn't you know what you output device is??
> >
> > If I send it to a typesetter or outsource print house, for example.
> >
> >
> > > >** Impelemeting EPS support from scratch would be less work, thou... :)
> > >
> > > I assume you mean simply supporting embedded EPS inside of Abi -
> > > and not actually parsing EPS, right?
> >
> > Yes, correct. Fully adequate EPS support does not require parsing
> > EPS.
> > 1> Load the contents of the EPS file, store it.
> >
> > 2> Allow the user to position & size a rectangle on
> > the document. Traditionally this rectangle contains
> > nothing but a label.
> >
> > 3> At print time, set the scale of the EPS to fit the
> > rectangle. Dump the contents of the EPS file directly
> > to the output device.
> >
> > That's why it's called embedded postscript.
> >
> > Later, Abi could use ImageMagik to parse the EPS for preview purposes ONLY.
> > On screen preview would be bitmap, vector data would be sent to the
> > printer.
> >
>
> We could also plug abi's xp graphics context to be another ghostscript
> driver and use ghostscript to draw the postscript to the screen at
> whatever resolution abiword is running.
>
> However a better long term solution is to convert the ps to our native
> vector graphics format and then print the vector graphics the same way we
> always do..
>
> That way we have an any vector -> native then native => any output, the
> way we do with bitmap images.
>
> Actually I also the think our the vector graphic format SVG, should be a
> subclass of a general XML format handler.
>
> The we could subclass, MathML, SVG, gnumeric, gupppi, HTML. XHTML or any
> other XML based presentation for that.
Because I often produce quite complex PostScript that I'd like to embed
in a word processing document, I'd rather not have AbiWord do this.
Each translation comes with risk of errors. If it's correct as PostScript,
and going to PostScript printer (or ghostscript printer) then why insert
multiple translations? Only translate it when necessary.
-Bryce
This archive was generated by hypermail 2b25 : Tue Dec 25 2001 - 16:25:59 CST