Hi Martin On 18.02.2009 07:33:55 Martin Edge wrote: > Hi Jeremias, > > Is this a IF XML structure change? Or merely the way it's being processed?
I'm not sure how much you picked up from the discussions so I'll start at the beginning (just to be sure): The "IF branch" introduces a completely new XML-based intermediate formats for FOP. The old one (the Area Tree XML, the one you use) still exists with no changes and will continue to be available. I know this might create some confusion which is why I tried to make it especially clear in the documentation how they stand to each other and which one should be used in which case. Both have their use cases. I've updated the documentation already but it's not live on the website as it's still only found in the branch. However, you can read through the documentation sources here: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml?view=markup (please don't look to closely at the name of the branch. It's misleading.) We continue to use the Area Tree XML format as our primary format for layout engine tests as it contains more information than the new one. So in short: the old IF is renamed to "Area Tree XML" (with no changes to it) and the new IF becomes our main "IF" (a completely new format optimized for speed). The API for working with it is a different one although similar to the Area Tree XML format. > I make changes to the IF prior to rendering my final document as I need to > put information on each page generated and be aware of the total amount of > pages rendered (a barcode as it was). These IF-related changes are 100% backwards-compatible. Don't worry. The only thing that might require someone's attention is if someone has a subclass of one of the deprecated Renderers. But depending on what you're doing you might want to investigate if the newly won performance (with the new IF) is actually something you could profit from. Of course, that will mean some work for you because it's a different format. But given the performance increase it might be worth it. > When you say deprecate following implementations, do you mean the fact that > the IF previously held some reference on what type of output the IF was > created for? What we discuss to deprecate are the Renderer implementation for PDF, PS, AFP, PCL and TIFF, i.e. PDFRenderer, PSRenderer, AFPRenderer, PCLRenderer and TIFFRenderer. These classes would be taken off the service registration file or the RendererFactory class will simply let the new IFDocumentHandler/IFPainter implementations take precedence if they are available. If you select the output format in code through its MIME type, you won't notice the change. An example: if you select "application/postscript" now, RendererFactory will instantiate an instance of PSRenderer. After these changes, RendererFactory will create an IFRenderer instance which will delegate to the new class PSDocumentHandler (and PSPainter). > Where can I get more information on this change? The original idea was developed on this Wiki page: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign The updated documentation (as already mentioned above) can currently be read from here: http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_AreaTreeNewDesign/src/documentation/content/xdocs/trunk/intermediate.xml?view=markup I've also made performance measurements as part of this effort which highlights why it was done in the first place: http://people.apache.org/~jeremias/fop/benchmark-2009-02-13/ I hope that clears up everything. If not, please don't hesitate to say so. I'm actually very happy to see stakeholders speak up. The more feedback there is the easier it is to make everyone happy (or as happy as is possible). > Thanks :-) > > Martin. > > > > -----Original Message----- > From: Jeremias Maerki [mailto:d...@jeremias-maerki.ch] > Sent: Tuesday, February 17, 2009 3:12 AM > To: email@example.com > Subject: Issues for after the IF branch merge > > Follow-up issues for after the merge where I'd be glad for feedback: > > - The new implementations currently all use a MIME suffix ";mode=painter". > They are now sufficiently tested that I'm confident that we can switch over > to them by default. One idea would be to put a switch in RendererFactory so > we can say: prefer IFDocumentHandler instead of Renderer implementation. Or > rather the opposite: by default use the IFDocumentHandler but allow to > switch to the old mode should there be an unexpected incompatibility. Good > idea or bad? > > - Given the performance figures I think it would be possible to deprecate > the following implementations: PDF, PS, PCL and AFP. As for the Java2D > implementations: the PNG, Print and AWT Preview parts are not implemented, > yet, so a deprecation here is premature. TXT is probably good enough like it > is. No change necessary there. After all, we won't deprecate the Renderer > interface itself. Good idea or bad? > > - A note primarily for Max: For JEuclid to work with the new > implementations, it will require an ImageConverter implementation (from XML > Graphics Commons' image loading framework). I haven't investigated how hard > it would be to provide a compatibility layer so the old implementations > could be used. The old stuff is in many parts tied into the Renderer > architecture. For Barcode4J, I've written such an implementation already. I > can also try to find time to do it for you, if you like. The good thing is > that the ImageConverter implementation is not FOP-specific but can also be > used by anyone using the image loading framework. Actually, that part might > influence the decision for the first and second points above! > > > Jeremias Maerki > Jeremias Maerki