xmlgraphics-fop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Xmlgraphics-fop Wiki] Update of "AreaTreeIntermediateXml" by JeremiasMaerki
Date Thu, 08 Sep 2005 09:42:40 GMT
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:
First draft for a proposal on an intermediate XML format for Apache FOP

New page:
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.

= Requirements =

 * The area tree should be serializable in an XML format so it can be easily manipulated.
 * The intermediate XML format should later be reread and normally rendered through FOP's
Renderers.
 * 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... :-)
 * The implementation must not have a negative impact on performance for people who don't
use the intermediate format.

= Benefits =

The intermediate format allows various manipulations of the layouted document. People can
do stuff that they can't do during the XSL-FO stage and that they'd have to do by post-processing
FOP's output, but after they already lost some information on the way (like the simple-page-master
used by a page).

= 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.

= 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.
 * 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.
   * 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.
 * 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.

= Additional ideas =

 * Someone could come up with a FOP extension which includes an intermediate format XML file
which could automatically be included at a certain point while rendering the main document
(Document insertion). If someone implements PDF parsing, the same could be done for PDF.

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


Mime
View raw message