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
