Re: AW: enhancing rtf support
On Aug 24, 2005, at 22:46, Peter Herweg wrote: Hi Peter, The tables don't work because I iterate recursivly through the FO and its child-nodes. But the TableColumn objects are not added to ChildNodes of the Table object. Instead they are added to a separate Array, so do also TableFooter and TableHeader (refer to Table.addChildNode). Of course i can consider this when I iterate the FO and additionaly iterate these arrays. But I'am afraid this will end up with a lot of "if"s and "else if"'s in order to process all necesarry FOs. Well, concerning the increase in conditional branches, I must say I feel more or less the same way about them, but still IMO, in most situations that's more a matter of aesthetics than of efficiency. A carefully chosen set of tests put in the right order doesn't have to cost that much in terms of performance/resources. I guess that what I mean is: I wouldn't worry *too* much about that type of issues ATM. If you can make it work *with* a lot of conditional branches, then by all means, go for it. Afterwards we can still start thinking about ways to cut those down to a minimum. I explicitly say 'we' because, however badly you may feel about the looks of the code, once it's in the repository, more eyes can look at it, so you have an increased probability of *someone* coming up with ideas on how to improve it. If there is nothing, any potential developer would have to start from scratch, which is even less desirable than a few if-else-if's too many. In this case, if the increased number of conditional branches results in increased functionality, I think that would be well worth the trade. One simply CANNOT expect to be able to extend functionality without having to pay a price for it somewhere... Cheers, Andreas
AW: enhancing rtf support
> I don't like the idea of removing functionality. Yes, I agree with you. >> (2) I want to test support for fo:table. This had worked quite good before i >> introduced the delaying. But now the table-columns get not processed. This >> will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. > >Can this not be achieved with (1) still in place? I'm sure, this is possible. But i don't think the current one is the best way. The tables don't work because I iterate recursivly through the FO and its child-nodes. But the TableColumn objects are not added to ChildNodes of the Table object. Instead they are added to a separate Array, so do also TableFooter and TableHeader (refer to Table.addChildNode). Of course i can consider this when I iterate the FO and additionaly iterate these arrays. But I'am afraid this will end up with a lot of "if"s and "else if"'s in order to process all necesarry FOs. > Sounds like a lot of work to me and prone to the sorts of problems you > mentioned above. Maybe you are right. Guess i have to decide this very carefully. Thank you for your advice. Kind regards, Peter Herweg -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Chris Bowditch Gesendet: Mittwoch, 24. August 2005 09:44 An: fop-dev@xmlgraphics.apache.org Betreff: Re: enhancing rtf support Peter Herweg wrote: > Hello fop-team, > > i'd like to spend again some time with enhancing the RTF support. I have > been inactive for over a year now (sorry, i was quite busy). Do you want me > to send patches, because i was inactive for such a long time? Or can i > access the svn repository? > I have received the fop-dev-mailing list, but usually have only read the > subject lines. Welcome back and as Jeremias said, its okay to commit without sending patches. > > I'd like to accomplish following tasks: > (1) FOP has already support for white-space-treatment, linefeed-treatment > and white-space-collapse. But the results of these implementations are only > availabe in RTFHandler.endBlock. So i had introduced delaying processing of > the FOs until endBlock. Unfortunatelly this makes the code quite complex and > buggy, so i want to remove this (of course the rtf module won't support > above mentioned attributes any longer). I don't like the idea of removing functionality. I read point (4) below and see that you intend to support for white-space-treatment again, but you can't think of a new approach. I think I understand the problem and I also think the current solution is the only one! So stick with it and see if you can fix the bugs. > (2) I want to test support for fo:table. This had worked quite good before i > introduced the delaying. But now the table-columns get not processed. This > will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. Can this not be achieved with (1) still in place? > (3) Add support for baseline-shift="sub" and baseline-shift="super". Cool. > (4) After all that i have to think about how we can get > white-space-treatment, linefeed-treatment and white-space-collapse to work. > The difficulty is that RTFHandler handles text nodes in its implementation > of FOEventHandler.characters. But at this time FOP's algorithms have not > been run. Currently i see three possibilities (just ideas: any comment > appreciated): >a. Find a solution without delaying processing any FOs. (I don't know how > this could work, in spite of implementing the complete algorithm by myself > just for the RTFHandler. Maybe this is the worst solution.) IIUC you are saying you don't know how to solve (1) another way, which is why I think you should not remove that code. >b. Find a solution by delaying *every* FO. This would make the > FOInputHandler interface useless, because i just had to wait for a > particular event (e. g. endPageSequence) and then iterate the passed > PageSequence object. Would be a great effort and would introduce the same > problems as described in (1). This is the current solution and the only realistic one IMHO. >c. Maybe i should not process the text nodes in FOEventHandler.characters > but simply add a placeholder to my rtf. When i reach endBlock i have to > iterate the passed Block object and search only for FOText objects. The > contents of these FOText's have to replace the placeholders. Sounds like a lot of work to me and prone to the sorts of problems you mentioned above. Chris
Re: enhancing rtf support
Peter Herweg wrote: Hello fop-team, i'd like to spend again some time with enhancing the RTF support. I have been inactive for over a year now (sorry, i was quite busy). Do you want me to send patches, because i was inactive for such a long time? Or can i access the svn repository? I have received the fop-dev-mailing list, but usually have only read the subject lines. Welcome back and as Jeremias said, its okay to commit without sending patches. I'd like to accomplish following tasks: (1) FOP has already support for white-space-treatment, linefeed-treatment and white-space-collapse. But the results of these implementations are only availabe in RTFHandler.endBlock. So i had introduced delaying processing of the FOs until endBlock. Unfortunatelly this makes the code quite complex and buggy, so i want to remove this (of course the rtf module won't support above mentioned attributes any longer). I don't like the idea of removing functionality. I read point (4) below and see that you intend to support for white-space-treatment again, but you can't think of a new approach. I think I understand the problem and I also think the current solution is the only one! So stick with it and see if you can fix the bugs. (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. Can this not be achieved with (1) still in place? (3) Add support for baseline-shift="sub" and baseline-shift="super". Cool. (4) After all that i have to think about how we can get white-space-treatment, linefeed-treatment and white-space-collapse to work. The difficulty is that RTFHandler handles text nodes in its implementation of FOEventHandler.characters. But at this time FOP's algorithms have not been run. Currently i see three possibilities (just ideas: any comment appreciated): a. Find a solution without delaying processing any FOs. (I don't know how this could work, in spite of implementing the complete algorithm by myself just for the RTFHandler. Maybe this is the worst solution.) IIUC you are saying you don't know how to solve (1) another way, which is why I think you should not remove that code. b. Find a solution by delaying *every* FO. This would make the FOInputHandler interface useless, because i just had to wait for a particular event (e. g. endPageSequence) and then iterate the passed PageSequence object. Would be a great effort and would introduce the same problems as described in (1). This is the current solution and the only realistic one IMHO. c. Maybe i should not process the text nodes in FOEventHandler.characters but simply add a placeholder to my rtf. When i reach endBlock i have to iterate the passed Block object and search only for FOText objects. The contents of these FOText's have to replace the placeholders. Sounds like a lot of work to me and prone to the sorts of problems you mentioned above. Chris
Re: enhancing rtf support
Welcome back! On 23.08.2005 20:12:21 Peter Herweg wrote: > Hello fop-team, > > i'd like to spend again some time with enhancing the RTF support. I have > been inactive for over a year now (sorry, i was quite busy). Do you want me > to send patches, because i was inactive for such a long time? Or can i > access the svn repository? You can simply start committing to the SVN repository. Just make sure you've run "svnpasswd" in your shell account to set the password for Subversion. I've just added your permissions to the FOP repository which I left off when migrating from CVS to SVN. See also: http://www.apache.org/dev/version-control.html Make sure you check out with the "https" prefix and not with "http" or you won't be able to commit. > I have received the fop-dev-mailing list, but usually have only read the > subject lines. > > I'd like to accomplish following tasks: > (1) FOP has already support for white-space-treatment, linefeed-treatment > and white-space-collapse. But the results of these implementations are only > availabe in RTFHandler.endBlock. So i had introduced delaying processing of > the FOs until endBlock. Unfortunatelly this makes the code quite complex and > buggy, so i want to remove this (of course the rtf module won't support > above mentioned attributes any longer). > (2) I want to test support for fo:table. This had worked quite good before i > introduced the delaying. But now the table-columns get not processed. This > will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. > (3) Add support for baseline-shift="sub" and baseline-shift="super". > (4) After all that i have to think about how we can get > white-space-treatment, linefeed-treatment and white-space-collapse to work. > The difficulty is that RTFHandler handles text nodes in its implementation > of FOEventHandler.characters. But at this time FOP's algorithms have not > been run. Currently i see three possibilities (just ideas: any comment > appreciated): >a. Find a solution without delaying processing any FOs. (I don't know how > this could work, in spite of implementing the complete algorithm by myself > just for the RTFHandler. Maybe this is the worst solution.) >b. Find a solution by delaying *every* FO. This would make the > FOInputHandler interface useless, because i just had to wait for a > particular event (e. g. endPageSequence) and then iterate the passed > PageSequence object. Would be a great effort and would introduce the same > problems as described in (1). >c. Maybe i should not process the text nodes in FOEventHandler.characters > but simply add a placeholder to my rtf. When i reach endBlock i have to > iterate the passed Block object and search only for FOText objects. The > contents of these FOText's have to replace the placeholders. I can't comment in detail to everything you write here as I really want to concentrate on other areas. I'm very happy that you're back taking care of the RTF output. For many of my customers RTF is a big topic even though it's a crappy format, entirely dependent on MS Word releases. The tasks above are well-chosen, I think. It should bring the RTF output forward quite a bit. Anyway, if I were you I'd try to see if you can profit from FOP's FO tree where you can because it already does a lot for you (handling inheritance and default values foremost). Please also make sure to keep the independence of the basic RTF library in place. It is now entirely self-sufficient and is bound to migrate to XML Graphics Commons. Only the FO-specific code will remain in FOP. Jeremias Maerki
enhancing rtf support
Hello fop-team, i'd like to spend again some time with enhancing the RTF support. I have been inactive for over a year now (sorry, i was quite busy). Do you want me to send patches, because i was inactive for such a long time? Or can i access the svn repository? I have received the fop-dev-mailing list, but usually have only read the subject lines. I'd like to accomplish following tasks: (1) FOP has already support for white-space-treatment, linefeed-treatment and white-space-collapse. But the results of these implementations are only availabe in RTFHandler.endBlock. So i had introduced delaying processing of the FOs until endBlock. Unfortunatelly this makes the code quite complex and buggy, so i want to remove this (of course the rtf module won't support above mentioned attributes any longer). (2) I want to test support for fo:table. This had worked quite good before i introduced the delaying. But now the table-columns get not processed. This will be fixed when (1) is finished. Sorry, i didn't notice this malfunction. (3) Add support for baseline-shift="sub" and baseline-shift="super". (4) After all that i have to think about how we can get white-space-treatment, linefeed-treatment and white-space-collapse to work. The difficulty is that RTFHandler handles text nodes in its implementation of FOEventHandler.characters. But at this time FOP's algorithms have not been run. Currently i see three possibilities (just ideas: any comment appreciated): a. Find a solution without delaying processing any FOs. (I don't know how this could work, in spite of implementing the complete algorithm by myself just for the RTFHandler. Maybe this is the worst solution.) b. Find a solution by delaying *every* FO. This would make the FOInputHandler interface useless, because i just had to wait for a particular event (e. g. endPageSequence) and then iterate the passed PageSequence object. Would be a great effort and would introduce the same problems as described in (1). c. Maybe i should not process the text nodes in FOEventHandler.characters but simply add a placeholder to my rtf. When i reach endBlock i have to iterate the passed Block object and search only for FOText objects. The contents of these FOText's have to replace the placeholders. Kind regards, Peter Herweg
