[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:
Intermediate format approach will need to be changed

------------------------------------------------------------------------------
  
  = Possible Problems =
  
-  * The area tree is currently not 100% self-sufficient. There are references to the FO tree, for example. (this has been mostly resolved)
+  * The area tree is currently not 100% self-sufficient. There are references to the FO tree, for example. (this has been resolved)
   * Different renderers provide different font sources. Rendering a document with a different font source from the one the document was laid out with may produce unexpected results.
-  * OffDocumentItems are direct signals to the Renderers which not really part of the area tree. Therefore, they are not serialized with the intermediate format. The PS-Extensions can be improved to make them XMLizable, but BookmarkData may be a little more complicated.
+  * OffDocumentItems are direct signals to the Renderers which not really part of the area tree. Therefore, they are not serialized with the intermediate format. The PS-Extensions can be improved to make them XMLizable, but BookmarkData may be a little more complicated. (this has been resolved)
  
  = Implementation notes =
  
@@ -46, +46 @@

   * Fonts are a special problem: It uses the internal key ("F1", "F2" etc.) to point to the right font. For the area tree, this should be reworked to contain the info on the exact font used during layout. The renderer will have to lookup the font once more to get at the font metrics if it needs them. If a serialized area tree is deserialized later, we need to be able to find out if a font is suddenly not available anymore. We shouldn't do any font substitution anymore in this case. More details here: http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200512.mbox/%3c20051222140018.6FF8.DEV@jeremias-maerki.ch%3e
   * The first version is now in SVN: [http://svn.apache.org/viewcvs?rev=369753&view=rev Revision 369753]. It doesn't support advanced operations such as n-ups, yet.
  
+ = Feedback from users =
+ 
+ 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.
+  * 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.
+ 
+ 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.
+ 

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