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
