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: Added an idea related to the IF & changed proposed split interface names ------------------------------------------------------------------------------ * 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. + == Resource Management (Idea) == + + Some formats like PostScript and AFP require special processing to optimize resources (images, fonts etc.). The PostScript renderer currently supports an optional two-pass approach where the resources are only added in the second pass to the beginning of the PostScript file, i.e. after you know which resources are needed. The idea now is to enrich the IF renderer with a mechanism to track track used resources so a second pass can be avoided when producing the final output format. After all, the IF renderer already processes the full document and knows which resources are necessary. + + We can make three categories of renderers: + + 1. no resource optimization (Java2D-based output formats, PCL, Text, SVG) + 1. implicit resource optimization (PDF due to its object structure, Mars) + 1. explicit resource optimization (PostScript, AFP) + + Please note, that this mechanism is only useful to the third category, so the mechanism will not be enabled unless done so explicitely. For formats like PDF this processing is not necessary since resources are added as they are needed. + + We define a listener interface that receives notification of resource usage ('''!ResourceUsageListener'''). The '''!RenderingResource''' interface will be implemented by a handful of classes (at the beginning: !FontResource & !ImageResource). The object identity of these classes is defined by what the IF supports: + + * Font: font-family, -weight, -style, -variant, -size + * Image: URI + + We need some infrastructure to keep track of resource usage on page-, page-sequence- and document-level. The most important is page-level. The other levels just summarize the accumulated data. Keeping track of resources down to page-level serves the following purposes: + + * Formats like PostScript note which resources are used by page. + * The IF can be split and merged. Resource usage on document-level alone would not be sufficient to list which resources are effectively used in the final print file. + + The resource usage information can optionally be integrated into the IF. For this purpose the IF is extended by a structure that is inserted into the page trailer and the document trailer. If desired the IF renderer could also support writing a separate file parallel to the generated IF, if the information needs to be tracked somewhere (could be implemented as a special resource listener). + + Subformat: + {{{ + <resource-usage> + <font family="Arial" weight="normal" style="normal" variant="normal" size="10pt" count="1"/> + <image uri="http://xmlgraphics.apache.org/fop/images/logo.jpg"; count="1"/> + </resource-usage> + }}} + + On a side-note, resource counting will allow to only move resources to the document resources which are needed on more than one page. Resource on the target device can become too high if every resource is moved to the document resources unconditionally. + + This whole idea adds some complexity but will make it possible to avoid a two-pass approach for PS and AFP generation which causes a reduction of through-put. + == TODO == * [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 - * [OPEN] Decide whether to split IFPainter into IFDocumentPainter and IFPagePainter to reduce the number of methods per interface. + * [OPEN] Decide whether to split IFPainter into IF!DocumentHandler and IFPainter to reduce the number of methods per interface. == Comments == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
![http://xmlgraphics.apache.org/fop/images/logo.jpg"](http://xmlgraphics.apache.org/fop/images/logo.jpg"){kind=link}