Re: AW: RTF export enhancement
- original Nachricht Betreff: AW: RTF export enhancement Gesendet: Mi 01 Mär 2006 14:50:54 CET Von: "Peter Herweg"<[EMAIL PROTECTED]> > > Jeremias Maerki wrote: > > 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. > Currently the class TableContext keeps track of the various columns. It's > also > responsible for cell-spannings and widths. I'll take this into consideration (I prefer re-use/improvement of code, needs some time to have a look at it, but prevents it from getting messy and some kind of patchwork) Thanks so far, I'll do this today/tomorrow... > > Kind regards, > Peter Herweg > > --- original Nachricht Ende "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
AW: RTF export enhancement
> Jeremias Maerki wrote: > 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. Currently the class TableContext keeps track of the various columns. It's also responsible for cell-spannings and widths. Kind regards, Peter Herweg
Re: RTF export enhancement
Sounds good so far except maybe one point. You only talk about the available page width, but if you place a table inside an fo:block which uses start-indent, end-indent, margin-left etc. (possibly even nested more than one level deep), the whole thing gets a little more complicated. It means that you need to keep track of the available widths on each nesting level. This is something the percentage contexts have to handle somehow. Good luck! On 28.02.2006 21:17:49 b.ohnsorg wrote: > > - 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 t
Re: Re: RTF export enhancement
- 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 (forma
Re: RTF export enhancement
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
RTF export enhancement
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 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? (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...) 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*... "Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken" www.klarmobil.de/index.html?pid=73025
