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

[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 ChrisBowditch:
http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml

The comment on the change is:
corrected a couple of typos

------------------------------------------------------------------------------
   * It should be possible to combine XML files from multiple rendering runs into one document which is then rendered by FOP's Renderers.
   * The intermediate format should make it possible to add graphical elements after processing, for example for OMR marks and barcodes for packaging control.
   * Allow imposition functions, two-up, n-up, page overlays, scaling and rotation of whole pages.
-  * One party that approached my wants to to manual modifications on leaf level to modify the appearance of the document, for example, squeezing in one more line of text or something like that. Adventurous, but if they are so brave... :-)
+  * One party that approached me wants to do manual modifications on leaf level nodes to modify the appearance of the document, for example, squeezing in one more line of text or something like that. Adventurous, but if they are so brave... :-)
   * The implementation must not have a negative impact on performance for people who don't use the intermediate format.
  
  = Benefits =
@@ -19, +19 @@

  = Possible Problems =
  
   * The area tree is currently not 100% self-sufficient. There are references to the FO tree, for example.
-  * Different renderers provide different font sources. Rendering a document with a different font source from the one the document was layouted with may produce unexpected results.
+  * 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.
  
  = Implementation notes =
  
   * 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 and 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.
+  * 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:
-    * The XMLRenderer is used. The problem here is that the renderer would have to be changed here are there and almost certainly in a way that would make changes in many layout engine test cases necessary.
+    * 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.
     * SAX-based serialization is implemented directly on the area classes. 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 teached 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.
+  * Adding a wrapper around a !PageViewport to do things like two-up and overlays should be easy. The Renderers will be tought 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.
   * 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.
   * It should be noted that with this design, there will be no direct painting routines. Additional graphics will need to be included as !ForeignObjects in SVG or another format wrapped in a positioned Block area.

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