----- original Nachricht -------- Betreff: Re: RTF export enhancement Gesendet: Di 28 Feb 2006 13:57:15 CET Von: "Jeremias Maerki"<[EMAIL PROTECTED]>
> > On 28.02.2006 12:34:37 b.ohnsorg wrote: > > Hi there, > > > > 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. Maybe the term "problem" is not correct, would be better to sum up facts (the way it is) that cause a problem (the way it works). > 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. Mkay, was only an argumentative chain...starting point for that page-sequence-master defaulting behaviour > 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. It is all about the calculation of the column widths. RTF does not support proportional values, so it is necessary to recalculate them to twips. To determine the whole table's width you need to know the page's width and this depends on the margins and so on...if a page sequence uses a page-sequence-master it's not possible to determine the correct size (due to the fact, that you never know, on which page [odd/even] you are)... > 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. I had a look at it and it's not that hard. > > ...a mechanism to get the document's margin or to imply, that > > page-sequence-master-pages are either odd or blank... > > Where possible common code can be factored > out. At some points this may not be possible. ...maybe creating a FlowPercentBaseContext, operating with only a set of margins, page width...(I'd say it doesn't make sense to be that specific in an AbstractPercentBaseContext, but could need some time to exclude that possibility) > > > (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 only question is: How is it possible to ask the RTFHandler about the "current page's" size...emphasized to get back to the 3 points mentioned before: If there is no simple-page-master for the current page-sequence RTFHandler is doomed... > > > 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. mkay, no prob, I need a working RTF export, so it's not only for the sake of mankind *g* To draw a conclusion, I'd implement according to the following sketch: 1. RTFHandler is able to get certain types of RTF-elements from the stack (handle to get the current table) 1.1 extend the RTF table with a list of columns (if not already present), recording the widths (in FO datatypes!) 1.2 If the first row occurs, get the table, calculate the column widths, stream (if possible/necessary) 2. RTF output is mainly to create a basic document structure which will be post-edited (formatting does not have to be so close to the PDF output) 2.1 RTFHandler also understands page-sequence-masters (until now it ignores non-simple-pm-s) 2.2 RTFHandler determines the current page-sequence's width according to the following algorithm: 2.2.1 simple-page-master?simple-page-master.width:2.2.2; 2.2.2 page-sequence-master?page-sequence-master.odd:2.2.3; 2.2.3 page-sequence-master?page-sequence-master.blank:2.2.4; 2.2.4 raise error (maybe default to the page size) 3. Convert FOUnits to twips 3.1 mm -> use implemented 3.2 pt -> use implemented 3.3 percentage -> calculate from total area width (Handler's current page width, RTF-object's size&indenting) 3.4 proportional -> calclulate from total area width (Handler's current page width, RTF-object's size&indenting) 4. RTFHandler gets an inner class, realizing PercentBaseContext 4.1 interface to the FO-object's width 4.2 can be moved outside 4.3 stays invisible to other parts of the code Afterall this first shot causes no changes in the more abstract parts like the FO tree. Everything stays within the RTF rendering package. I'd try to finish this 'til friday, have some testing and send the modified classes to you (or others?) for review and further discussion. Maybe this gets too abstract without code to read through.
