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
