Mark C. Allman schrieb:
What I do now is the following:
doc.xml --------------| doc.pdf
|--> XSLT ENGINE --> doc.fo --> FOP --> { doc.rtf }
translator_doc.xsl --| .....
Putting something into FOP to generate ODF wouldn't make much sense,
IMHO. I think it'd just be another xslt script to translate the FO file
to ODF.
I investigated in the same area one year ago and came to the conclusion:
1) It is easier to do it direct from XML than to parse a fo-file:
>> XML + XSLT-ENGINE —> ODF
> Or write a plug-in for OpenOffice to read in FO files
> (obviously another project!).
2) Yes this would be a propper place, but the work is the same:
file.fo --> OpenOffice-import-filter --> file.odf or
file.fo --> FOP --> file.odf sounds very similar
from the point of what has to be done ;-)
> I use the RTF generation so that I can then convert a few things to MS
> Word (can't ignore the 800 pound gorilla in the room). > I think
we'll lose users if we don't keep something that lets them
generate docs that are interoperable with the 800 pound gorilla. How we
do that is the question.
OpenOffice could be another heavy wight gorilla in this chain:
file.fo --> FOP --> file.odf --> OpenOffice --+--> file.rtf
+--> file.doc
+--> file.pdf
Yes, I have to confess that I think that in some cases (beeing able to
do small last adjustments with an WYSIWYG tool) this chain would be
usefull and pdf-generation would be for free. This is not a competition
for FOP because it has its advantages in interactive usage while FOP has
its advantages in automated environments without user-interaction.
file.fo --> FOP --> file.rtf has the same benefit and has the advantage
of an existing implementation but on the long run I think ODF should be
kept in mind.
gerhard
