On 28.02.2006 12:34:37 b.ohnsorg wrote:
> Hi there,
> the FOP sources are quite complex and it's not the amount of classes but
> the patchwork style, which is necessary, to a certain extent. I'll
> return on this in a later mail. To upgrade the RTF export (proportional
> and percentage-based widths) I need further information. I could find
> nothing helpful on RTF's future:
> 1. RTF is not rendered page oriented. Therefore it has no layout tree
> and renders to it's own tree-structure.
> 2. FO allows page-sequence-master which refer to simple-page-master ->
> every page sequence has no infomation object (for margin wrapper...)
> 3. A column list is necessary, when it comes to proportional widths

Point 1 is certainly not a problem but a fact. RTF is a stream-oriented
format (as is XSL-FO) and is expected to be converted like this from
XSL-FO. That's why the layout engine doesn't kick in. If you want RTF to
be rendered in a page-oriented way, you have to write a new renderer.
But this approach would mean you predetermine all page breaks which
could lead to problems for users who want to edit the generated RTF
document. And that, BTW, is the most important reason why people use RTF.

Point 2: Not all the FO features can be mapped into RTF, I think. The
mapping has to be done as well as possible. Anyway, I don't fully
understand what you're trying to say there.

Point 3: Yes, for tables, you will somehow need to keep track of the
various columns. I don't know the details of the current table support
in RTF in detail so I can't help off-hand. Maybe Peter Herweg can help
some more.

> These are not problems, which cannot be solved. But this implies, that I
> misuse a PercentBaseContext to retrieve the width property from the
> flow.TableColumn (...holding the Length-realization...raising the
> RuntimeException when getValue() is invoked) and that I insert (or reuse?)
> a mechanism to get the document's margin or to imply, that
> page-sequence-master-pages are either odd or blank. After that I can
> save all the proportional values to some column list and calculate when
> the first table row is inserted. Other ideas, suggestions, hints,
> strategies?

No really. It is likely that to a certain degree some functionality that
was implemented in the layout engine (layout managers) has to be redone
for flow-oriented formats. Where possible common code can be factored
out. At some points this may not be possible.

> (Have a look at the RTFHandler-class, connecting the fo-events to
> methods which create the necessary RTF-objects. These take care of the
> OutputStream and convert their values via the FoUnitsConverter. This
> converter cannot deal with proportional values, cause it has no link to
> the total width, which is provided by the PercentBaseContext-realizer,
> e.g. LayoutManager...)

Yes, to do the percentages properly the whole percentage infrastructure
has to be built into the RTFHandler somehow. If it's possible to extract
that part from the layout managers, all the better, but there may not be
an easy way. Some code duplication may be unavoidable.

> The table cell indenting is a minor change and only an additional "\li0"
> to RTF's column wrapper class. (The table inherits the enclosing
> paragraph's indenting which causes the cell content to be indented like
> a paragraph. This must be reset in every row and get the correct value
> from the cell's padding.)
> Thanks for your patience *g*...

Thanks for diving into this stuff. We can use all the help we can get.

Jeremias Maerki

Reply via email to