[Xmlgraphics-fop Wiki] Update of "AreaTreeIntermediateXml" by JeremiasMaerki

[Apache Wiki <wi...@apache.org>]

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:
Preparing for notes on new proposed design

------------------------------------------------------------------------------
  This page describes a proposal for an intermediate XML format in which FOP's area tree can be serialized and reread for delayed rendering. I've been approached by two parties who would like to have such a feature in FOP.
+ 
+ As is indicated below, the currently implemented intermediate format needs a different approach. The design ideas and discussion are found on the AreaTreeIntermediateXml/NewDesign page.
  
  = Requirements =
  
@@ -55, +57 @@

  
  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.
  
- So, the idea now is to specify a new intermediate format which will cover the original requirements (as seen above) and fix the above two problems. The rough idea is to simplify the intermediate format. That will mean that we will need a different approach for the Renderers. In the short term the original renderers will remain untouched. Maybe at some point they can be replaced by the new counterparts which are expected to be smaller and easier to develop since they don't have to cover the same amount of functionality as the current ones. The new intermediate format will be specified shortly on a separate page on this Wiki.
+ So, the idea now is to specify a [wiki:Self:AreaTreeIntermediateXml/NewDesign new intermediate format] which will cover the original requirements (as seen above) and fix the above two problems. The rough idea is to simplify the intermediate format. That will mean that we will need a different approach for the Renderers. In the short term the original renderers will remain untouched. Maybe at some point they can be replaced by the new counterparts which are expected to be smaller and easier to develop since they don't have to cover the same amount of functionality as the current ones. The current XMLRenderer will likely remain in place for the time being if only to help with unit testing the layout engine.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org