[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-cvs
Subject:    [Xmlgraphics-fop Wiki] Update of "AreaTreeIntermediateXml" by JeremiasMaerki
From:       Apache Wiki <wikidiffs () apache ! org>
Date:       2007-02-28 13:48:38
Message-ID: 20070228134838.11852.42106 () eos ! apache ! osuosl ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]