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
