On 21.12.2007 16:01:22 Vincent Hennebert wrote: > Hi, > > In theory this would be more logical to finish implementing the features > that the spec does describe. However, I can hear the business > motivations behind this proposal. I have nothing against it, I just > won’t try and make a big effort to provide support (either dev or user). > > So this is a +0 from me. > > A few comments inline. > > Jeremias Maerki a écrit : > <snip/> > > <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" > > What about 1,3-5,7,11-? :-P
I want to keep it simple for now. Adding that later will be easy. > > 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). > > But PDFBox will still be necessary to insert the external document in > the sequence of pages? Just curious. If you want to insert a PDF file, yes, my plug-in and PDFBox will be necessary. But for inserting multi-page TIFFs (faxes, for example), PDFBox won't be necessary as I strictly use the features of our existing area tree to position the images. The new ExternalDocumentLayoutManager simply creates a new page sequence in the area tree with the minimal elements necessary to paint the image. The individual sub-images will be addressed using URIs in the form: http://localhost/images/myimage.tif#page=3 > <snip/> > > 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, > > Do we really care about that? :-P “Sorry, it only works with FOP, > you’ll have to use FOP to benefit from this feature.” Isn’t that > a shame. Hehe. > > > 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. > > As long as it doesn’t turn the current architecture upside down. But > I guess it won’t, will it? No, the implementation was quite easy and relatively non-invasive. However, I've created a new superclass for PageSequence and PageSequenceLayoutManager which fleshes out shared functionality and fields into a common base class, for example, for the whole page number and ID handling. That could mean some increased complexity in understanding the PageSequenceLayoutManager but it also could also be the opposite since the topics are better grouped together: ID handling, page production, layout control.... > > 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. > > Which makes FOP live, anyway. > > > > WDYT? > > Have fun ;-) Fun's already over. It's working. But more fun is waiting. And having a few days off will be fun, too. Jeremias Maerki
