Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml/NewDesign The comment on the change is: More details on the Java side and performance considerations ------------------------------------------------------------------------------ * The intermediate format has to become much easier and faster to parse. * Benefit: the renderers may be become leaner and therefore easier to maintain and implement. * Difficulty: features needed in the future (mainly: tagged PDF) could become a little more difficult since a graphical metafile will not contain structure information per se. OTOH, the current area tree doesn't have enough structure information, either. - * Difficulty: until now, supporting extension was relatively easy as each area tree object could carry extension attributes. With a graphical metafile, individual area tree object cannot directly be identified in the stream anymore. + * Difficulty: until now, supporting extensions was relatively easy as each area tree object could carry extension attributes. With a graphical metafile, individual area tree object cannot directly be identified in the stream anymore. * When going in this direction, one question is obvious: Why not take SVG (or Adobe Mars) as the intermediate format? It would most probably be much slower than an optimized, proprietary format. But what if we restricted ourselves to a subset and didn't use Batik for the rendering? Just a thought. * It is worth noting that the working draft SVG 1.2 specification would provide pagination for the layout with the <page/> and <pageSet/> elements (see http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html) [2]. + + * It is important to note that the XML representation of the area tree is still very important. The new IF is no replacement for unit testing the layout engine because the area tree contains much more verbose information of the layout result. + = Sketching out a new XML format = {{{ @@ -71, +74 @@ [http://people.apache.org/~jeremias/fop/renderer-design-new.png] + == IFPainter design == + + IFPainter (working title, better suggestions welcome!) is a central interface, like Renderer. There's one implementation for each output format that is useful in the context of the intermediate format (probably includes all current renderers except text. most important are: PostScript, AFP and PCL). Ideally, the IFPainter interface is a direct equivalent to the possible SAX stream for the new IF format, i.e. it is possible to convert between IFPainter and the IF-NG SAX stream with no losses. The IFContentHandler in the graphic above would convert the SAX stream to IPPainter calls and a special IFPainter implementation used by IFRenderer could convert the calls to the SAX stream. That way, the IFRenderer could actually render to an IFPainter without the detour over XML. + + The IFPainter interface is not fully designed, yet, so the following is just to give an idea what it could look like (all methods will probably throw SAXException): + + {{{ + public interface IFPainter { + + //for foreign content and extensions + ContentHandler getContentHandler(); + + void startDocument(); + void endDocument(); + + void startDocumentHeader(); + void endDocumentHeader(); + + void startPageSequence(String id); + void endPageSequence(); + + void startPage(int index, String name); + void endPage(); + + void startPageHeader(); + void endPageHeader(); + + void startPageContent(); + void endPageContent(); + + void startPageTrailer(); + void addTarget(String name, int x, int y); + void endPageTrailer(); + + void startBox(AffineTransform transform, Dimension size, boolean clip); + void startBox(String transform, Dimension size, boolean clip); + //For transform, something like Batik's org.apache.batik.parser.TransformListHandler/Parser can be used + void endBox(); + + void setFont(String family, String style, Integer weight, String variant, Integer size, String color); + //All of setFont()'s parameters can be null if no state change is necessary + void drawText(int[] x, int[] y, String text); + void drawRect(Rectangle rect, String fill, String stroke); + void drawImage(String uri, Rectangle rect); //external images + void startImage(Rectangle rect); //followed by a SAX stream (SVG etc.) + void endImage(); + //etc. etc. + } + + public class IFState { + + //all font traits + //list of transforms since the last state safe (by startBox()) + //maybe the effective clip shape + } + + //additional needed classes + public class IFSerializer implements IFPainter { + + public IFSerializer(ContentHandler handler) { + [..] + + //convert IFPainter calls to XML (IF-NG) + } + + public class IFContentHandler implements ContentHandler { + + public IFContentHandler(IFPainter painter) { + [..] + + //convert SAX stream calls to IFPainter calls + + } + }}} + + Note that the IFPainter should be designed so it is easy to write some kind of filter (like !FilteredOutputStream) where implementors can react to certain events like startPageContent() so they can add their own content calls (content enrichment) for things like barcodes, OMR marks, background images etc. + + === Performance evaluation compared to previous approach === + + Performance is expected to be higher for the following reasons: + + * We have fewer content elements which accounts for a leaner implementation and reduction to essential content. No potentially empty container structures like we have now. + * Currently, the IF is implemented over our area tree which contains a generic structure for traits. Maps present a certain amount over overhead by themselves which this approach avoids. Furthermore, the !AreaTreeParser has to inspect various trait sets per area tree object which causes too many Map operations. + * The conversion from !ContentHandler to IFPainter only requires one lookup (see !AttributesImpl.getValue()) per parameter. The number of parameters is very small. Some parameters are complex Strings which need to be parsed themselves (for example startBox()'s transform parameter). The overhead here should be relatively low since these are not extremely frequent operations. setFont()'s parameters could be changed from String to an enumeration class which would cause a Map lookup, but again setFont() is not a very frequent operation and not every parameter will be set and therefore parsed on every call. + == TODO == - * [done] Check usage of PPML in this context. (Result: Wouldn't really help in this context.) + * [done] Check usage of PPML in this context. (Result: Wouldn't really help in this context but the resemblance of the basic structure to the new IF is remarkable.) * [OPEN] Don't forget different writing modes == Comments == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
