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

The comment on the change is:
A few details what exactly is not good now

------------------------------------------------------------------------------
  2007-02-28: The intermediate format has been available for quite some time 
now. Users seem generally quite happy with the functionality. Two problems have 
been identified, however:
  
   * The current approach is too slow. The parser is quite complicated and not 
very fast (ex. many lookups necessary). The renderers contain quite a bit of 
logic to convert the area tree to the output format.
+    * Profiling on a document without custom fonts and images:
+      * Rendering takes about 50% of the time
+      * !AreaTreeParser$Handler.startElement() takes about 32% (a lot of 
overhead due to Map operations for traits during area tree build-up)
   * The XML format is a little complicated and too difficult to generate by 
hand and to get right.
  
  The original approach was tempting because it promised relatively quick 
results by reusing as much as possible. The main intention of the intermediate 
format is to have FOP process a document as far as possible, so that later in 
the final step the ultimate output format can be generated as quickly as 
possible. The use case behind this: Imagine a high-volume document production 
system where a lot of documents come in during the day. They are formatted as 
they come in (so they CPU consumption can be distributed during the day). At 
some point the printing department decides to print the queued documents. An 
operator issues a command to generate a big print job containing all queued 
documents. The documents (saved in intermediate format) are concatenated and 
enriched using OMR marks or barcodes for automated packaging and other things 
like job info pages and finally, they are run through a renderer to generate 
the desired output format (often !PostScript, AFP or PCL). This fina
 l task has to be very fast so the operator doesn't have to wait too long for 
the print job to be available for printing. Of course, the same could be done 
working in the actual output format (i.e. directly in !PostScript or AFP), but 
that means that this functionality would have to be implemented for each output 
format which with the intermediate format you'd have to do it once.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to