[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:
Minor updates

------------------------------------------------------------------------------
  
   * The first step will be to make the area tree self-sufficient to make it really reloadable.
   * There is a !CachedRenderPagesModel which is supposed to save pages in a file as long as they can't be rendered. This class is currently not used in FOP, but it would be good to make sure this class works again which will be a long way towards making sure that the first step is done.
-  * Serialization to XML can be implemented in two ways:
+  * Serialization to XML can be implemented in two ways (the first has been chosen):
     * The XMLRenderer is used. The problem here is that the renderer would have to be changed in a way that almost certainly would require changes in many layout engine test cases.
     * Serialization is implemented directly on the area classes by generating SAX events (like in ExampleObj2FO). This basically means duplicate work when we already have the XMLRenderer but it places the functionality in the "right" place and leaves the freedom to design this format as needed by the tasks that will be performed with it.
   * The Bean-to-XML serialization available since JDK 1.4 cannot be used due to JDK restrictions.
   * It's probably best to implement parsing via SAX again to avoid dependencies on other XML libraries like Digester.
   * Adding a wrapper around a !PageViewport to do things like two-up and overlays should be easy. The Renderers will be taught to handle this additional wrapper object and will simply set up the target coordinate system accordingly. This will have no influence on the relative coordinate handling while rendering the actual area objects. This could also be implemented directly on the PageViewport but with the wrapper the actual area tree can be left untouched.
   * Foreign XML content (from i-f-o) will be serialized in their proper namespaces in the intermediate format. That allows the XMLHandlers to still optimize the rendering of foreign XML dialects. Some improvements in the infrastructure around this may be necessary, but should not be a big deal.
-  * We will need to provide an API to handle the generation of the area tree XML. Furthermore, we need functions to load the intermediate format and to render it.
+  * We will need to provide an API to handle the generation of the area tree XML (this is done through the normal XMLRenderer now). Furthermore, we need functions to load the intermediate format and to render it (see AreaTreeParser).
   * It should be noted that with this design, there will be no direct support for elements in the area tree namespace to perform painting operations (for shapes, for example). Additional graphics will need to be included as !ForeignObjects in SVG or another format wrapped in a positioned Block area.
  
  = Additional ideas =
@@ -43, +43 @@

  
   * Trying to reactivate the CachedRenderPagesModel shows several problems with the current area tree: Instances of ColorTypeProperty and Font, for example are not serializable. Being a Serializable is not a strict requirement for implementing the intermediate format but it shows problem spots on the way to a fully reloadable area tree.
   * 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.
  

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