I have committed the classes from the jfor RTF library under org.apache.fop.rtf.rtflib.
They don't compile out of the box, so I disabled their compilation in build.xml for now, didn't have time to look further.
The next step would be to get them to compile, have the RTFHandler use them and remove jfor.jar from the lib directory.
You will probably find dependencies to other parts of jfor, let me know if you need more classes (but hopefully most of those dependencies are not needed).
...I don't want
to mislead anyone into thinking I'm making a big commitment here -- it will
probably be a little here and a little there...
fine - we'll see what happens!
...Java source is Unicode, and I don't think the encoding would matter, but
UTF-8 makes the most sense as most of the source is ASCII. And it could be
that most tools don't care, but I know that JBuilder does...
yes, idea for example uses a configurable file encoding.
...if there is some doc on the RTF libs,
there is none ATM.
...t seems like the wiki said to look at how the conversion tools used them, but that didn't seem to help much.
Feel free to ask if you have questions. There is also the testdocs package some parts of the RTF library.
Does it make sense in the long run for the jfor libs to be a separate project? It seems like it should have wider appeal than just for FOP, although FOP is probably a good home for it for now.
I think FOP is a good start. It would be easy to create a separate rtflib.jar if needed.
By creating another project we would lose the FOP community, it is certainly better at this point to strengthen it by adding new features to FOP.
What's sorely missing IMHO is a way to validate the generated RTF other than by crashing word processors. If you hear about an RTF validator or an RTF parser grammar it would be a welcome improvement.
-Bertrand
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
