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]

Reply via email to