The latest RTF Spec (1.7), pertaining to Word 2002 is at:

Self Extracting exe with the Word doc inside.

Scott Sanders

-----Original Message-----
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, November 27, 2001 3:40 AM
Subject: Re: Merging jfor into FOP - what's the plan?

Hi Arved,

> What are your recommendations for someone to come up to speed with

I'd recommend to stay away from it unless you really have to ;-)
Seriously, to someone accustomed to clear and well-defined specs, RTF is

somewhat messy, what it is really is a documented internal format, not a
that has been agreed upon by a carefully-selected comittee.

The RTF spec that we use in jfor is (mostly) V1.5 from Microsoft, who
moved on to 1.6 (at least), but apparently 1.5 is the most widely
spec. A google search shows it at, it
be harder to find at Microsoft as it's not the latest.

The rtflib package of jfor (available at encapsulates our 
knowledge of RTF and is fairly simple and understandable, but it is
still too 
much element-oriented.
One important thing to realize (happened too late here) is that RTF is 
more flow-based or stack-based than element-based: not everything that
opened has to be closed, it's more like a flow with embedded attribute 

> As I understand it, RTF is presented
> to a user-agent which does a fair amount of layout; higher-level
> are still present in the RTF. 

Right - but there are both structure and presentations codes, so an RTF 
document could be both. 
Jfor has a strong bend towards structure, as usually the user goal is to
an editable RTF document, where as much of the original document
must be preserved for convenience. 
Precise appearance usually comes second, as applying a new wordprocessor

style sheet can change a lot of it.

RTF is both a presentation and a structure format, along with a moving
due to the "spec" being expanded and rewritten with nearly every new
of winword. 
There are a many grey areas in the spec, meaning the only possible test
opening the generated RTF in the desired wordprocessors (and often
it crash...).

> <snip>
> This is not so different from MIF
Agreed. We are working with MIF for another project, and didn't choose
for that because of lack of precise control over the MIF output.

I tend to see these formats as:
-PDF for finished high-quality output ("presentation language"), layout
done by FOP

-MIF for semi-finished high-quality output ("typography language"),
done by Framemaker according to MIF instructions.

-RTF for editable structure + presentation output ("wordprocessing 
language"), layout done by wordprocessor.

So I fully agree that MIF and RTF "renderers" share a lot in common - 
they must be able to get as much information as possible about the
document structure, and in my view do not need any layout computations.

> In a sense with RTF and MIF (and HTML for anyone who really
> wants to see FO->HTML) we are talking about translators as opposed to
> formatters and renderers...

yes - that's why I called jfor a "converter" instead of "formatter"

Without knowing too much about FOP internals, I think a processing chain

along these lines might help:

parsing if needed
-> SAX events
-> FO attributes processing (validation, inheritance) 
-> StructureRenderer

StructureRenderer is
EITHER Layout + PrintRenderer
OR StructureProcessor (RTF, MIF, etc.)

What we need to find out is how much the existing FOP and these
renderers" have in common.

- 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