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 > 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. <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. > 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? > 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 ;-) Vincent -- Vincent Hennebert Anyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
