Bertrand Delacretaz wrote:
> Maybe a new build target that creates a standalone fop-rtflib.jar would
> be good?
> I'd still keep rtflib in the main fop.jar, but offer a standalone
> rtflib in addition.
+1
> Note that the interest for a MIF renderer is probably lower than it was
> before, as newer versions of FrameMaker can import XML directly and
> combine it with (homegrown) style mappings.
Good point. However, I know that I have some interest in it, because of the
ability to use XSLT for the style mappings instead of Frame. To make this
work, we need (and probably need anyway, and can probably expect to see in a
future FO standard) the ability to create styles in FO. I may propose such
an extension in the future, but I'll probably defer it as long as possible
in the hopes that the FO standard will get there first.
BTW, I have a big beef with Adobe (FrameMaker) and Corel (WordPerfect) for
claiming that their products support XML, when they use proprietary
character sets, and have *no* way to deal with Unicode.
> An alternative would be to define constants in interfaces
> (RtfAlignConstants, RtfParaConstants etc) to group them, and have the
> classes that use them implement these interfaces to make the values
> directly available. This would be more compatible with the existing API
> I think.
Good idea. I'll think on this a bit.
> > ...have changed
> > RtfParagraph.writeRtfPrefix() to write the text attributes as well as
> > the
> > paragraph attribute....
>
> If one can still set text attributes on individual text runs inside a
> paragraph as well, then fine.
Yes.
> I'm not happy with the current design of RtfText embedded in
> RtfParagraph - although this maps well to the XSL-FO model
> ("elements"), it does not map well to the RTF model ("text runs" I
> think, but still somewhat mysterious after all these years ;-).
> This causes problem in jfor where nested paragraphs and inlines are
> sometimes output in the wrong order. I think a "flatter" design of the
> RtfText vs. RtfParagraph model would help.
Yes, I ran into this in what I thought would be a trivial exercise of adding
background colors to paragraphs. If you set the color at the beginning of
the paragraph, it affects the rest of the document. My tentative solution
was to simply keep track of the "state" of the concept on the FOP side, and
look for changes. However, I expect that we can throw more of this burden
onto the RTFLib side, perhaps with a configurable option that could either
favor an element-driven approach or a text-run-driven approach. The \par vs.
\pard might help in this regard.
It sounds like we are on the same page so far. Please let me know if you see
me heading off in a bad direction.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
