FYI, I've now already got working code for FOP Trunk including documentation but without multi-page support which I'll add in the image package branch. I know it's nearly weekend and Christmas but I'd still like to commit this by next Wednesday or Thursday. So if anyone has anything against this please let me know.
On 20.12.2007 10:38:05 Jeremias Maerki wrote: > I've been playing with the idea for some time and the time has come to > bring this up. I would like to write an FO extension which allows to > insert a multi-page document into an FO document, so each page produces > a new page of exactly the same dimensions as the bitmap image in the > final format (by default). With fo:external-graphic it's only possible > to embed one single image somewhere inline. Of course, it's possible to > position the fo:external-graphic so it takes up the whole page and you > can even address individual pages (<uri>#page=3) with the new image > package but you'd still need to know at least the number of pages at > XSLT time to get this right. Instead, I'd like to do this with a single > extension element on the same level as fo:page-sequence. I've called it > fox:external-document for now. Here's the proposed specification: > > fox:external-document > > Child of: fo:root > Contents of fo:root would be changed to this: > (layout-master-set,declarations?,bookmark-tree?,(page-sequence|page-sequence-wrapper|fox:external-document)+) > > The fo:external-document extension element is used to generate a > (sub-)sequence of pages where each page will contain the necessary areas > to display each page of a potentially multi-page document on a separate > page. > > The size of each sub-image will define the size of the page it generates > unless the width, height, content-width, content-height properties are > used. > > Contents: > EMPTY > > The following properties apply: > - (Common Accessibility Properties) > - (Common Aural Properties) > - block-progression-dimension > - content-height > - content-type > - content-width > - display-align > - height > - id > - inline-progression-dimension > - overflow > - pages: <page-set> (see below) > - reference-orientation > - scaling > - scaling-method > - src > - text-align > - width > > <page-set>: > Value: auto | <integer-range> > Default: "auto" which means all pages of the document. > integer-range allows values such as "7" or "1-3" > > Benefits of the extension: > - It is mostly useful for multi-page TIFF files (scanned documents and > faxes) and PDFs (with my PDF-in-PDF plug-in). > - It removes the necessity to post-process the generated output file > (for example with PDFBox or iText). It's not necessary to implement this > post-processing for each output format in use and it's not necessary to > manually play with the intermediate format to add this functionality. > - Attaching existing PDF files to PDFs generated by FOP has been a > frequent topic on fop-users. > - FOP could be used this way to convert multi-page TIFF files to PDF or > whatever output formats FOP supports. We could provide a command-line > option for that if we want. > > While writing this it occurred to me that this could also be implemented > as an FO-preprocessor (SAX filter). However, since this proprocessor > would have to generate page masters depending on the images which have > to be inserted at the beginning of the FO file, this could be > inefficient. The only benefits I see is that it could be used with other > FO implementations, too, and that it wouldn't add code to FOP which has > to be maintained. So, I would prefer to implement this as a layout > manager. > > I know this is again something that doesn't really bring FOP closer to > version 1.0. Again, it's simply coming from people using FOP on a > day-to-day basis. > > WDYT? > > Jeremias Maerki > Jeremias Maerki