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