On 30.08.2005 01:24:07 Stephen Denne wrote:
> 
> Jeremias Maerki wrote:
> > So please help us with the development or at least share with us your
> > concrete requirements! Maybe yours are different than mine.
> 
> I was intending to help with the development, but unfortunately a change to
> the business environment that I am in has meant that I don't think I will
> have the chance.

:-(

> > > In addition, the ability to say where the added postscript 
> > code is to go
> > > would be useful. e.g. first thing in the page vs. last 
> > thing in the page.
> > 
> > Are you talking about adding PostScript code for OMR marks or other
> > marks to control the packaging process?
> 
> Yes, identifying each page, in case the machine that careful places our
> perfectly rendered pages into envelopes, decides to practice modular
> origami.
> 
> We run FOP multiple times, and in parallel, then join together all the
> output postscript files as desired. In doing so we insert separation pages,
> change page numbering based on plexing of output printed from various
> printers, add OMR, etc.
> 
> Of use to us here would be the ability to identify resources (fonts and
> images) used in the documents, inserting short postscript macros to
> reference them during rendering, merging the lists of used resources from
> the parallel runs, then produce a single postscript header defining all the
> resources, with the names already used in the rendered documents. Obviously
> this is way beyond the scope of XSL-FO. FOP could possibly extend the
> FormattingResults to include lists of which fonts were actually used, and
> which images were used. I know that this could be determined by parsing the
> input FO, but I'm addicted to making code fast, and don't like doing things
> twice when once is sufficient.

Something like that could be done easily. I've already improved the
PostScript generation code a lot to make stuff like this easier. The
only difficulty are fonts which are always a little special.

I've thought about implementing a special PS generating mode which
doesn't even process images, for example, but only outputs the
references to an image as DSC comments. That would save a lot of file
size and processing time. The images would never have to be fully loaded,
only their headers analyzed, thus saving lots of memory, too.

> One requirement (that I am pleased to see you continuing) is the very high
> degree of similarity between PDF output and postscript output.

Yes, that proved to be very important to many people in the past.

> Obviously the font handling code has a large impact here.

Absolutely.

> A recent problem we have had is with the differing environment that Batik
> runs in when rendering for PDF and for postscript, specifically the
> identification of font resources that should be used, and why the PDF
> renderer starting asking for the Dialog font-family.

Test cases would be welcome here to improve on that.

> Anyway, this is getting off topic, sorry.

Not at all off-topic if you ask me. That's exactly the kind of stuff I
want to hear.


Jeremias Maerki

Reply via email to