Hi, Bertrand What are your recommendations for someone to come up to speed with RTF? I (and possibly others) need to understand RTF better in order to assist.
The existing renderers for PDF, Postscript, XML and AWT can all handle raw areas...they do no layout whatsoever. As I understand it, RTF is presented to a user-agent which does a fair amount of layout; higher-level structures are still present in the RTF. This is not so different from MIF, and in fact, when the MIFRenderer was originally written, there _were_ some problems (as I recall) in working from the area tree directly. For example, MIF understands tables - this information needed to be passed along whereas other renderers no longer cared about such semantics. Since the MIFRenderer is somewhat moribund (I think) then jfor really becomes the prototype for a different class of formatter/renderers, operating in parallel with the existing code for PDF etc. It would be interesting to see if we can do things in such a way so as to resurrect MIF also, since I think it never ought to have been a renderer in the first place. In a sense with RTF and MIF (and HTML for anyone who really desperately wants to see FO->HTML) we are talking about translators as opposed to formatters and renderers...again, correct me if I am wrong, but the output of the translator is presented to a user-agent that will actually be doing layout. Regards, Arved Sandstrom At 08:43 AM 11/27/01 +0100, Bertrand Delacretaz wrote: >Hi Keiron, > >If there is not going to be a FOP release in the next few weeks, I >agree that a minimal integration does not make sense. > >Currently the jfor conversion is driven directly from SAX events, so the >first thing that comes to mind is driving it from the FO tree. > >You're right that, contrary to print renderers, the RTF one will need to know >about the structure of the original document. > >Does the FO tree handle things like attribute inheritance (i.e. a block >inherits the font definition from an ancestor block), or is this handled >while doing the layout? Such inheritance is currently missing in jfor. > >To summarize: >-jfor needs to know about the original document structure: speaks for option >(A), plugging jfor right after the FO tree stage if I understand well. > >-BUT jfor could probably benefit from some operations done at the layout >stage (attributes inheritance, others?) : speaks for option (B), extending >the renderer interface to let the renderers know (cleanly) about the original >document structure. > >If you can give me some pointers about where to look at in the code to >evaluate (A) and (B), I'll have a look. > >- Bertrand > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
