On 02.08.2005 11:44:23 guillaume wrote:
> > - in rtfdoc.BorderAttributesConverter:
> > - 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...
> The same goes for the render.rtf.FOPRtfAttributes import.
> With this and all that was described in my previous message (subject:
> "rtflib independance from FOP") an rtflib.jar (which I now eventually have
> a need for) can be build and used independantly from FOP! :)
> I can make a patch for that, but I need some feedback regarding the
> suggested interface addition and method removal, so please speak up!
As long as you preserve the existing functionality, you're free to
propose any changes. If the RTF library is useful without XSL-FO, that's
absolutely fine and we can make sure in the future that it stays that
> And also I am not really sure whether the most up-to-date version of
> rtflib lies in FOP or in JFOR... Could someone please clarify this?
JFOR has been integrated in FOP, so FOP is not the most up-to-date
> Jeremias : what about JAFOG (Java API for Formatting Objects Generation)?
Thanks for the suggestion. However, "formatting objects generation"
sounds almost like we're generating FO, not that we consume FO, and in
the meantime the API can do more than just consume XSL-FO. It can handle
any XML-based format which produces graphical output (like XSL-FO, SVG,
MathML, you name it).
> P.S.: All readers please appect my apologies for not responding on the
> right threads! (I have not subscribed to the ML (yet) as I can currently
> only read my mail from a web-mail ATM and believe me it is a real PITA...)
Poor guy. I heard some people are quite happy with accessing lists
through GMANE (http://gmane.org/) but I haven't tried it myself.