AW: PDF output driver
Let's talk component software (or blame monolithic MicrosSoft)! - Formatting has to be separated strictly from rendering o A clean and stable interface has to be defined (why not by data representations of powerful PDF?) o The renderer has to control the processing sequence. - FOP does what the XSL:FO specs say - no more and no less: o external-graphics are not really specified in XSL:FO, so let additional attributes pass and let the renderer do the job. o foreign-object is by chance SVG: let foreign be foreign and pass foreign-object's without checks thru to the renderer. The area of contributors and hackers is renderers and foreign-objects, so that the FOP core can be kept clean and preserved from release dependencies (Batik, JAI etc.) Hansuli Anderegg, Zurich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF output driver
On Tue, 2002-07-23 at 00:10, Kevin O'Neill wrote: I'm new to fop, so please give me a little leeway :). I've been looking at FOPs PDF library to help me with some direct PDF generation tasks that are not presently suited to XSL:FO (I need absolute positioning, layering and the ability to use XObject Forms). FOP has about the nicest and low level PDF library I've come across, a true undiscovered gem. Enough of the glowing praise :). I've noticed from the CVS logs that the separation of the PDF code is a recent thing; are there current plans to extend it's usefulness beyond that of mealy being an output renderer for FOP? There aren't any specific plans in that direction but you can always make some if you want :) Would you consider adding contributed classes (like the aforementioned XObjectForm) that there is no real XSL:FO imperative for? I was considering using XObject forms to render embedded svg so that it can be reused in the pdf document without redrawing the svg (for static regions etc.). So there may well be an XSL:FO use for it anyway (along with other ideas like reusing for table headers, static regions that are the same on each page). So we would definitely consider it! Separating the generation of the PDF support into an additional build target for people like me who what to use the PDF functionality without the additional XSL:FO components? I don't see why not. In general it is a good idea to keep independant parts of the code separate. This will promote that more. We now have a pdf-transcoder target that builds just a jar that can be used as a transcoder for batik. We could split things up further and have: pdf jar, svg stuff jar, hyph jar, the rest jar. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF output driver
I'm new to fop, so please give me a little leeway :). I've been looking at FOPs PDF library to help me with some direct PDF generation tasks that are not presently suited to XSL:FO (I need absolute positioning, layering and the ability to use XObject Forms). FOP has about the nicest and low level PDF library I've come across, a true undiscovered gem. Enough of the glowing praise :). I've noticed from the CVS logs that the separation of the PDF code is a recent thing; are there current plans to extend it's usefulness beyond that of mealy being an output renderer for FOP? Would you consider adding contributed classes (like the aforementioned XObjectForm) that there is no real XSL:FO imperative for? Separating the generation of the PDF support into an additional build target for people like me who what to use the PDF functionality without the additional XSL:FO components? Regards, -k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PDF output driver
I'm new to fop, so please give me a little leeway :). I've been looking at FOPs PDF library to help me with some direct PDF generation tasks that are not presently suited to XSL:FO (I need absolute positioning, layering and the ability to use XObject Forms). FOP has about the nicest and low level PDF library I've come across, a true undiscovered gem. Enough of the glowing praise :). I've noticed from the CVS logs that the separation of the PDF code is a recent thing; are there current plans to extend it's usefulness beyond that of mealy being an output renderer for FOP? Would you consider adding contributed classes (like the aforementioned XObjectForm) that there is no real XSL:FO imperative for? Separating the generation of the PDF support into an additional build target for people like me who what to use the PDF functionality without the additional XSL:FO components? Regards, -k. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
