On 01.08.2005 16:57:28 guillaume wrote: > Hello, > > While looking for a RTF text encoder (for accentuated characters), I gave > a closer look at rtflib (in xml-fop_20050717162512.tar.gz).
Uhm, I don't think we have current CVS snapshots anymore since we moved to Subversion some time ago. Seems to be a left-over that we need to get rid of. Please download the sources using Subversion. Subversion has the advantage over CVS that it works over HTTP and therefore passes most Firewalls and Proxies. > It seems that here still a few dependancies on FOP in it. I understand it > is not a priority for the FOP-Team right now, but if it can help in some > way, here they are: > > - in rtfdoc.RtfGenerator there is a call to Fop.getVersion() juste to > print the FOP version, and that obviously pulls all the FOP classes: this > could easily be removed by adding a "generator" String parameter on the > constructor (as the generator RTF metadata is optional, one could even > keep the old constructor for compatibility) > - in rtfdoc.BorderAttributesConverter: > - fo.Constants is imported but it seems acceptable as it brings no other > dependancy > - fo.properties.CommonBorderPaddingBackground is imported but is only > used by makeBorder(), which is not used anywhere in rtflib.**, so > perhaps this could be alleviated too... Want to send a patch? :-) > Sorry my dependancies checks are not fool-proof as I had neither eclipse > nor grep to check, only Windows and few spare time to do it... > > I must had that I do not need a self-contained rtflib anymore right now, > as what I needed is nicely self-contained in rtfdoc.RtfStringConverter: > keep it that way if you can! :) I don't see why we couldn't. > Good luck for the upcoming release! Thanks. > P.S.: Please respond also to my address if possible as I have not > subscribed to this list... We'd prefer if you would subscribe if you want to take part in the discussions. Thanks for your feedback! Jeremias Maerki