You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@anyware-tech.com> on 2007/07/31 14:48:04 UTC
Drop RTF Support?
Hi,
There have been various questions on fop-user recently regarding the RTF
output of FOP. Personally I’m incapable of helping in this area, and
also most unwilling to.
Tell me if I’m wrong, but I suspect that in the current team there is
about one person who could help / modify the code, and who wouldn’t be
very willing to either.
More and more often people who ask questions regarding RTF are answered
that going the OpenDocument (or similar XML format) route might be more
successful. So, I’m wondering if we shouldn’t drop support for RTF in
the next release.
Not completely, of course, but basically we wouldn’t advertise it, and
say that RTF support is provided as is, is no longer maintained, and
that users are on their own when using it. That way they would at least
be aware of the risks of going that route.
WDYT?
Vincent
Re: Drop RTF Support?
Posted by ge...@ogersoft.at.
Mark C. Allman schrieb:
> Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
>
> Swap out RTF with, say, ODF? Sounds great to me.
>
> I'd even volunteer some time to help with development. I seem to
> remember something about Java.... ;-]
I started a ODF handler / ODF FO Eventhandler implementation by copying the
render/rtf source tree to a render/odf tree (using eclipse) and did adjusted the
import statements and did some renaming.
I added a new mimetype to the MimeConstants and added the necessary code to the
cli.CommandLineOptions and finaly replaced the rtf-mimetypes with the new
odf-mimetype in the ODFFOEventHandlerMaker.
I inserted in fop.tools and fop.tools.anttasks a correspondig line for odf
whereever I found rtf.
But after all the RendererFactory does not find the ODFFOEventHandlerMaker so I
want to ask if it must be registered in some way or what I have missed.
For now I hardcoded the maker to the discoverFOEventHandlers() method but I
think this is not the way to do it ;-))
gerhard
--
O(ettl) GER(hard)
Re: Drop RTF Support?
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 10, 2007, at 18:33, b.ohnsorg wrote:
> Nicol Bolas wrote:
>> ... I'm sorry. That didn't make sense.
>>
>> Could you please repeat it, using something more closely
>> resembling actual
>> English? I don't actually understand your point or even what your
>> sentences
>> are trying to say.
> It wouldn't make more sense if I'd try to say it in other words.
> Was my fault to try to express it in a language different from my
> mother tongue. (And it would be even harder for me to explain it
> even as native speaker to transport the idea of accepting things
> that don't make sense in any logical way but get payed at least.)
>
> So please drop RTF-export, 'cause it doesn't make sense to
> transform anything expressable by XSL-FO to something that 70% of
> «business people» use every day. And that's why everybody should
> get used to talk, write and understand XSL-FO. BTW, did you
> recognize that not even FOP is fully XSL-FO capable and some of the
> ideas behind XSL-FO can't be transformed with it to...Post Script?
> So please also drop XSL-FO-parsing-support from FOP.
:-) Now there's a point!
I agree. RTF does have its limitations, so does TXT. Still, there is
a TXT renderer incorporated in FOP. Should we drop it entirely,
because we ourselves don't have a need for it? Interesting to see so
many references to the sacred "XSL-FO Recommendation", but never a
single word about the fact that the Recommendation places *no
constraint whatsoever* on the *user agents*, only the *formatter*
matters.
If a certain output format happens to offer only very limited
features, should that format be dropped?
Note: XSL-FO contains /aural/ properties as well, to control audible
output. Those indeed make little sense when rendering to PostScript.
Bottom-line for me: I would not drop RTF-support. Too many people
have already invested their time in JFOR and its integration into FOP
to let that happen. Especially not when the original motivation seems
to be, yet again, an almost obsessive need to save on some
maintenance... ;-)
RTF is a reality. I'd rather receive a question every once in a while
and see people offering useful patches to improve its quality, than
move it to the sandbox and get washed away by a lot of "What happened
to RTF???" posts...
> To sum it up: my sentences don't try to say anything, that's why
> I'll do something different than wasting energy by sending mails to
> that list. I'm not pissed nor disappointed but I'm not eager enough
> to teach philosophy to everybody and start with the meaning of life
> to explain my point of view 'bout FOP and RTF-support. If it still
> doesn't make sense to you: I ought to start drinking before stop
> thinking.
Oh, I think you make perfect sense: there are boundaries to all
logical arguments. Points beyond which there simply is no point
anymore. :-)
Cheers
Andreas
Re: Drop RTF Support?
Posted by "b.ohnsorg" <b....@freenet.de>.
Nicol Bolas wrote:
> ... I'm sorry. That didn't make sense.
>
> Could you please repeat it, using something more closely resembling actual
> English? I don't actually understand your point or even what your sentences
> are trying to say.
It wouldn't make more sense if I'd try to say it in other words. Was my fault to try to express it in a language different from my mother tongue. (And it would be even harder for me to explain it even as native speaker to transport the idea of accepting things that don't make sense in any logical way but get payed at least.)
So please drop RTF-export, 'cause it doesn't make sense to transform anything expressable by XSL-FO to something that 70% of «business people» use every day. And that's why everybody should get used to talk, write and understand XSL-FO. BTW, did you recognize that not even FOP is fully XSL-FO capable and some of the ideas behind XSL-FO can't be transformed with it to...Post Script? So please also drop XSL-FO-parsing-support from FOP.
To sum it up: my sentences don't try to say anything, that's why I'll do something different than wasting energy by sending mails to that list. I'm not pissed nor disappointed but I'm not eager enough to teach philosophy to everybody and start with the meaning of life to explain my point of view 'bout FOP and RTF-support. If it still doesn't make sense to you: I ought to start drinking before stop thinking.
--
------
http://krachlattenpaul.homelinux.org
Home of Trackbase (1.3.0), VoiceLeadingCalculator (1.2.1) and
the immortal Swear-O-Tron...
Re: Drop RTF Support?
Posted by Nicol Bolas <jm...@comcast.net>.
... I'm sorry. That didn't make sense.
Could you please repeat it, using something more closely resembling actual
English? I don't actually understand your point or even what your sentences
are trying to say.
As to the point on CSS, nobody wants to use a broken CSS renderer. They
simply have to, and nobody likes that circumstance. Nobody's asking
Microsoft to make Internet Explorer non-CSS compliant.
b.ohnsorg wrote:
>
> Nicol Bolas wrote:
>> In any case, RTF lacks the full degree of expressiveness possible from
>> XSL-FO anyway, so some information is going to get lost. What's the point
>> of
>> doing the XSL-FO transform to begin with if you didn't want your stuff to
>> have a particular look to it? It's like wanting to use a broken CSS
>> renderer
>> for your HTML; you may as well not have bothered with the CSS to begin
>> with.
>>
> Did you ever argue with a sort of «big spender» about paying your ideas
> AND knowing, that he'll have to pay 100times more to get his workers on
> XSLT-level? Some people even don't care 'bout rockets flying through an
> empty space, reaching a «big rock» and sending back some stones, so why
> can't there be people who don't care 'bout what XSLT even means and have
> absolutely no idea of «document editing» beyond type->mark->make
> bold+underline? (And your CSS-argument is quite dangerous, some browser,
> only a few, very little *g* don't support CSS. Can you imagine, that it's
> not possible to have auto-content in something called Internet Explorer
> *g*? But you could use ActiveX to render nearly anything with curves,
> lines and realtime-3D, which would be even closer to reality...)
>
>
--
View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12083281
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
Posted by "b.ohnsorg" <b....@freenet.de>.
Nicol Bolas wrote:
> In any case, RTF lacks the full degree of expressiveness possible from
> XSL-FO anyway, so some information is going to get lost. What's the point of
> doing the XSL-FO transform to begin with if you didn't want your stuff to
> have a particular look to it? It's like wanting to use a broken CSS renderer
> for your HTML; you may as well not have bothered with the CSS to begin with.
>
Did you ever argue with a sort of «big spender» about paying your ideas AND knowing, that he'll have to pay 100times more to get his workers on XSLT-level? Some people even don't care 'bout rockets flying through an empty space, reaching a «big rock» and sending back some stones, so why can't there be people who don't care 'bout what XSLT even means and have absolutely no idea of «document editing» beyond type->mark->make bold+underline? (And your CSS-argument is quite dangerous, some browser, only a few, very little *g* don't support CSS. Can you imagine, that it's not possible to have auto-content in something called Internet Explorer *g*? But you could use ActiveX to render nearly anything with curves, lines and realtime-3D, which would be even closer to reality...)
Re: Drop RTF Support?
Posted by Nicol Bolas <jm...@comcast.net>.
You missed several important points, however.
First, ODF and OOXML are not WYSIWYG formats. They cannot do what XSL-FO
says that they should. So any transformation from XSL-FO to ODF or OOXML is
fundamentally wrong. It violates the XSL-FO specification in various ways,
and there's no way to know what the output will actually be.
XSL-FO processors don't exist to generate "something". They must generate a
specific thing (within tolerances, of course). They must do exactly what
they are told, as defined by the XSL-FO specification. And if an output
format can't handle what the spec says to do, then it is the output format
that is wrong.
The second problem is that ODF and OOXML have semantic constructs that
XSL-FO cannot replicate. Dates, chapters, etc, all of that information has
been lost by the time the FO was generated. So the ODF or OOXML files
generated from a FO will be, not wrong, but entirely unsemantic. Your
DocBook document with its nice chapters and so forth will end up with just
text. Formatted text, as per the FO, but the concept of chapters, articles,
etc, have all been lost, and ODF/OOXML have the semantic structures to
contain some of these.
So, from the perspective of making a proper XSL-FO implementation, ODF/OOXML
formats are bad. And from the perspective of making a good ODF/OOXML file,
using FO as a source is bad.
The best you could hope to get out of this code path is something that looks
OK. And what's the point of bothering to generate complex XSL-FO documents
if all that descriptive power goes to waste? I mean, XSL-FO has all of this
expressive power, and the most you can think to do with it is throw it away
on an ODF file?
I wouldn't mind using an XSLT to convert a FO into ODF/OOXML. But calling
such a thing a real "FO Processor" is simply untrue. All such a tool can do
is turn the FO into an office format that preserves a degree of readability.
Mark C. Allman wrote:
>
> Well...not exactly, IMHO.
>
>> What a person wanting to put documents in a Word-readable format wants
> is to
>> be able to take his original XML file and turn it into something that
> can be
>> used by someone else. In that case, what is necessary is an XSLT to
> convert
>> the XML into ODF or whatever.
>
> By analogy, if I want to put XML data in PDF format, do I write XSLT to
> convert it to PDF? We don't do that now. We write an XSLT script to
> covert to XSL-FO, then the FOP engine converts to PDF.
>
> The FOP engine is a converter from XSL-FO to something else. Word, ODF,
> RTF, PDF, text, whatever. We all already write XSLT scripts to
> transform from data (XML) to XSL-FO. I'm not trying to be argumentative
> at all, just also not demanding of a project team that's providing me a
> great tool at no cost to me. I'd like to keep RTF, or in it's absence
> have something I can use in its place. Also, people who ask for things
> should be prepared to chip in and help.
>
> BTW, also IMHO, it'd be cleaner to have one XSLT "super-script" to
> convert from XSL-FO to ODF (or OOXML or whatever Microsoft calls their
> "open" standard). If I write an XSLT script to transform data in XML to
> an ODF document then I write it for each schema. So if I want to
> generate both PDF and ODF then I'm forced to write two XSLT scripts (one
> to XSL-FO and another to ODF). If we wrote an admittedly rather complex
> XSLT script to transform from XSL-FO to ODF then we'd only write it
> once. It's an academic point, since I think writing such an XSLT script
> is outside the bounds of the FOP project. No scope creep here, please.
>
> Just my 2 cents....
>
> -- Mark C. Allman,
> PMP
> -- Allman
> Professional
> Consulting, Inc.
> -- 617-947-4263
> --
> www.allmanpc.com
>
>
>
--
View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12065161
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
Posted by Nicol Bolas <jm...@comcast.net>.
You missed several important points, however.
First, ODF and OOXML are not WYSIWYG formats. They cannot do what XSL-FO
says that they should. So any transformation from XSL-FO to ODF or OOXML is
fundamentally wrong. It violates the XSL-FO specification in various ways,
and there's no way to know what the output will actually be.
XSL-FO processors don't exist to generate "something". They must generate a
specific thing (within tolerances, of course). They must do exactly what
they are told, as defined by the XSL-FO specification. And if an output
format can't handle what the spec says to do, then it is the output format
that is wrong.
The second problem is that ODF and OOXML have semantic constructs that
XSL-FO cannot replicate. Dates, chapters, etc, all of that information has
been lost by the time the FO was generated. So the ODF or OOXML files
generated from a FO will be, not wrong, but entirely unsemantic. Your
DocBook document with its nice chapters and so forth will end up with just
text. Formatted text, as per the FO, but the concept of chapters, articles,
etc, have all been lost, and ODF/OOXML have the semantic structures to
contain some of these.
So, from the perspective of making a proper XSL-FO implementation, ODF/OOXML
formats are bad. And from the perspective of making a good ODF/OOXML file,
using FO as a source is bad.
The best you could hope to get out of this code path is something that looks
OK. And what's the point of bothering to generate complex XSL-FO documents
if all that descriptive power goes to waste? I mean, XSL-FO has all of this
expressive power, and the most you can think to do with it is throw it away
on an ODF file?
Mark C. Allman wrote:
>
> Well...not exactly, IMHO.
>
>> What a person wanting to put documents in a Word-readable format wants
> is to
>> be able to take his original XML file and turn it into something that
> can be
>> used by someone else. In that case, what is necessary is an XSLT to
> convert
>> the XML into ODF or whatever.
>
> By analogy, if I want to put XML data in PDF format, do I write XSLT to
> convert it to PDF? We don't do that now. We write an XSLT script to
> covert to XSL-FO, then the FOP engine converts to PDF.
>
> The FOP engine is a converter from XSL-FO to something else. Word, ODF,
> RTF, PDF, text, whatever. We all already write XSLT scripts to
> transform from data (XML) to XSL-FO. I'm not trying to be argumentative
> at all, just also not demanding of a project team that's providing me a
> great tool at no cost to me. I'd like to keep RTF, or in it's absence
> have something I can use in its place. Also, people who ask for things
> should be prepared to chip in and help.
>
> BTW, also IMHO, it'd be cleaner to have one XSLT "super-script" to
> convert from XSL-FO to ODF (or OOXML or whatever Microsoft calls their
> "open" standard). If I write an XSLT script to transform data in XML to
> an ODF document then I write it for each schema. So if I want to
> generate both PDF and ODF then I'm forced to write two XSLT scripts (one
> to XSL-FO and another to ODF). If we wrote an admittedly rather complex
> XSLT script to transform from XSL-FO to ODF then we'd only write it
> once. It's an academic point, since I think writing such an XSLT script
> is outside the bounds of the FOP project. No scope creep here, please.
>
> Just my 2 cents....
>
> -- Mark C. Allman,
> PMP
> -- Allman
> Professional
> Consulting, Inc.
> -- 617-947-4263
> --
> www.allmanpc.com
>
>
>
--
View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12065161
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
Posted by "Mark C. Allman" <mc...@allmanpc.com>.
Well...not exactly, IMHO.
> What a person wanting to put documents in a Word-readable format wants
is to
> be able to take his original XML file and turn it into something that
can be
> used by someone else. In that case, what is necessary is an XSLT to
convert
> the XML into ODF or whatever.
By analogy, if I want to put XML data in PDF format, do I write XSLT to
convert it to PDF? We don't do that now. We write an XSLT script to
covert to XSL-FO, then the FOP engine converts to PDF.
The FOP engine is a converter from XSL-FO to something else. Word, ODF,
RTF, PDF, text, whatever. We all already write XSLT scripts to
transform from data (XML) to XSL-FO. I'm not trying to be argumentative
at all, just also not demanding of a project team that's providing me a
great tool at no cost to me. I'd like to keep RTF, or in it's absence
have something I can use in its place. Also, people who ask for things
should be prepared to chip in and help.
BTW, also IMHO, it'd be cleaner to have one XSLT "super-script" to
convert from XSL-FO to ODF (or OOXML or whatever Microsoft calls their
"open" standard). If I write an XSLT script to transform data in XML to
an ODF document then I write it for each schema. So if I want to
generate both PDF and ODF then I'm forced to write two XSLT scripts (one
to XSL-FO and another to ODF). If we wrote an admittedly rather complex
XSLT script to transform from XSL-FO to ODF then we'd only write it
once. It's an academic point, since I think writing such an XSLT script
is outside the bounds of the FOP project. No scope creep here, please.
Just my 2 cents....
-- Mark C. Allman,
PMP
-- Allman
Professional
Consulting, Inc.
-- 617-947-4263
--
www.allmanpc.com
BusinessMsg -- the
secure, managed,
J2EE/AJAX
Enterprise IM/IC
solution.
On Wed, 2007-08-08 at 14:40 -0700, Nicol Bolas wrote:
> Ultimately, I guess, it depends on what you're using FOP for.
>
> I see XSL-FO as a means to print files. Or store them in a printable format.
> XSL-FO is not an interchange format; it is not PDF, nor should it be looked
> at as such. It exists to be converted into something based on the semantics
> defined in the XSL-FO specification.
>
> For all their promises of WYSIWYG, neither Word nor OpenOffice (nor the
> formats they read) are WYSIWYG. Their formats cannot exactly conform to the
> XSL-FO specification. They can come close, but they're not the same.
>
> What a person wanting to put documents in a Word-readable format wants is to
> be able to take his original XML file and turn it into something that can be
> used by someone else. In that case, what is necessary is an XSLT to convert
> the XML into ODF or whatever.
>
> In any case, RTF lacks the full degree of expressiveness possible from
> XSL-FO anyway, so some information is going to get lost. What's the point of
> doing the XSL-FO transform to begin with if you didn't want your stuff to
> have a particular look to it? It's like wanting to use a broken CSS renderer
> for your HTML; you may as well not have bothered with the CSS to begin with.
>
> Plus, there's the fact that ODF attempts to retain some basic semantic
> information, which has already been lost by the time the XSL-FO comes
> around. Since this information cannot be recovered, the ODF file produced
> from an XSL-FO would be, at best, visually functional. But ideas on what
> constitutes a title or whatever are completely lost. One would get much more
> functional ODF files by writing a custom XSLT for the format. Plus, the
> format isn't exactly that difficult to use.
>
>
> Mark C. Allman wrote:
> >
> > I only meant that if we replace the RTF capability with something
> > equivalent. 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 "ODF" was in the post I replied to, so I just used that as an
> > example.
> >
> > 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. Or write a plug-in for OpenOffice to read in FO files
> > (obviously another project!).
> >
> > 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.
> >
> > Just my 2 cents....
> >
> > -- Mark C. Allman,
> > PMP
> > -- Allman
> > Professional
> > Consulting, Inc.
> > -- 617-947-4263
> > --
> > www.allmanpc.com
> >
> >
> >
> >
> >
> >
> >
> >
> > BusinessMsg -- the
> > secure, managed,
> > J2EE/AJAX
> > Enterprise IM/IC
> > solution.
> >
> >
> >
> >
> >
> > On Wed, 2007-08-01 at 11:29 +0200, Vincent Hennebert wrote:
> >
> >> Hi Mark,
> >>
> >> Mark C. Allman a écrit :
> >> > Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
> >> >
> >> > Swap out RTF with, say, ODF? Sounds great to me.
> >> >
> >> > I'd even volunteer some time to help with development. I seem to
> >> > remember something about Java.... ;-]
> >>
> >> Thanks for your offer to help!
> >>
> >> However... would that make sense to produce ODF from XSL-FO? There is no
> >> semantic construction at all in FO, whereas there is some in ODF. The
> >> other way around looks much more useful to me; as style informations are
> >> stored using FO, this should be very easy to convert an ODF document
> >> into plain XSL-FO.
> >>
> >> Typically the transformation chain:
> >> XML —> XSL-FO —+—> RTF
> >> |
> >> +—> PDF
> >> would be replaced by:
> >> XML —+—> XSL-FO —> PDF
> >> |
> >> +—> ODF
> >>
> >>
> >> WDYT?
> >> Vincent
> >>
> >
> >
> >
> >
>
Re: Drop RTF Support?
Posted by Nicol Bolas <jm...@comcast.net>.
Ultimately, I guess, it depends on what you're using FOP for.
I see XSL-FO as a means to print files. Or store them in a printable format.
XSL-FO is not an interchange format; it is not PDF, nor should it be looked
at as such. It exists to be converted into something based on the semantics
defined in the XSL-FO specification.
For all their promises of WYSIWYG, neither Word nor OpenOffice (nor the
formats they read) are WYSIWYG. Their formats cannot exactly conform to the
XSL-FO specification. They can come close, but they're not the same.
What a person wanting to put documents in a Word-readable format wants is to
be able to take his original XML file and turn it into something that can be
used by someone else. In that case, what is necessary is an XSLT to convert
the XML into ODF or whatever.
In any case, RTF lacks the full degree of expressiveness possible from
XSL-FO anyway, so some information is going to get lost. What's the point of
doing the XSL-FO transform to begin with if you didn't want your stuff to
have a particular look to it? It's like wanting to use a broken CSS renderer
for your HTML; you may as well not have bothered with the CSS to begin with.
Plus, there's the fact that ODF attempts to retain some basic semantic
information, which has already been lost by the time the XSL-FO comes
around. Since this information cannot be recovered, the ODF file produced
from an XSL-FO would be, at best, visually functional. But ideas on what
constitutes a title or whatever are completely lost. One would get much more
functional ODF files by writing a custom XSLT for the format. Plus, the
format isn't exactly that difficult to use.
Mark C. Allman wrote:
>
> I only meant that if we replace the RTF capability with something
> equivalent. 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 "ODF" was in the post I replied to, so I just used that as an
> example.
>
> 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. Or write a plug-in for OpenOffice to read in FO files
> (obviously another project!).
>
> 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.
>
> Just my 2 cents....
>
> -- Mark C. Allman,
> PMP
> -- Allman
> Professional
> Consulting, Inc.
> -- 617-947-4263
> --
> www.allmanpc.com
>
>
>
>
>
>
>
>
> BusinessMsg -- the
> secure, managed,
> J2EE/AJAX
> Enterprise IM/IC
> solution.
>
>
>
>
>
> On Wed, 2007-08-01 at 11:29 +0200, Vincent Hennebert wrote:
>
>> Hi Mark,
>>
>> Mark C. Allman a écrit :
>> > Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
>> >
>> > Swap out RTF with, say, ODF? Sounds great to me.
>> >
>> > I'd even volunteer some time to help with development. I seem to
>> > remember something about Java.... ;-]
>>
>> Thanks for your offer to help!
>>
>> However... would that make sense to produce ODF from XSL-FO? There is no
>> semantic construction at all in FO, whereas there is some in ODF. The
>> other way around looks much more useful to me; as style informations are
>> stored using FO, this should be very easy to convert an ODF document
>> into plain XSL-FO.
>>
>> Typically the transformation chain:
>> XML —> XSL-FO —+—> RTF
>> |
>> +—> PDF
>> would be replaced by:
>> XML —+—> XSL-FO —> PDF
>> |
>> +—> ODF
>>
>>
>> WDYT?
>> Vincent
>>
>
>
>
>
--
View this message in context: http://www.nabble.com/Drop-RTF-Support--tf4192798.html#a12062102
Sent from the FOP - Dev mailing list archive at Nabble.com.
Re: Drop RTF Support?
Posted by ge...@ogersoft.at.
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
Re: Drop RTF Support?
Posted by "Mark C. Allman" <mc...@allmanpc.com>.
I only meant that if we replace the RTF capability with something
equivalent. 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 "ODF" was in the post I replied to, so I just used that as an
example.
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. Or write a plug-in for OpenOffice to read in FO files
(obviously another project!).
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.
Just my 2 cents....
-- Mark C. Allman,
PMP
-- Allman
Professional
Consulting, Inc.
-- 617-947-4263
--
www.allmanpc.com
BusinessMsg -- the
secure, managed,
J2EE/AJAX
Enterprise IM/IC
solution.
On Wed, 2007-08-01 at 11:29 +0200, Vincent Hennebert wrote:
> Hi Mark,
>
> Mark C. Allman a écrit :
> > Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
> >
> > Swap out RTF with, say, ODF? Sounds great to me.
> >
> > I'd even volunteer some time to help with development. I seem to
> > remember something about Java.... ;-]
>
> Thanks for your offer to help!
>
> However... would that make sense to produce ODF from XSL-FO? There is no
> semantic construction at all in FO, whereas there is some in ODF. The
> other way around looks much more useful to me; as style informations are
> stored using FO, this should be very easy to convert an ODF document
> into plain XSL-FO.
>
> Typically the transformation chain:
> XML —> XSL-FO —+—> RTF
> |
> +—> PDF
> would be replaced by:
> XML —+—> XSL-FO —> PDF
> |
> +—> ODF
>
>
> WDYT?
> Vincent
>
Re: Drop RTF Support?
Posted by ge...@ogersoft.at.
Vincent Hennebert schrieb:
> Hi Mark,
>
> Mark C. Allman a écrit :
>> Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
>>
>> Swap out RTF with, say, ODF? Sounds great to me.
>>
>> I'd even volunteer some time to help with development. I seem to
>> remember something about Java.... ;-]
I tried to play with ODF and therefore
- copied the render/rtf classes to render/odf (using eclipse)
- adjusted the imports
- did some renames (only classes in package org.apache.fop.render.odf,
that contan RTF but no renames in subpackages)
- added a new mime-type
- expanded the cli.CommandLineOptions
- added a odf line wherever I found rtf mime in fop.tools
Basicly it looks like the code has survived ;-) but the ODFEventHandlerMaker is
not discovered from RendererFactory.discoverFOEventHndlers so for now I
hardcoded an addFOEventHandlerMake to the end of that method, but think this is
not the way to do it ;-))
So the question is: what have I missed to get the ODFEventHandlerMaker which
returns the ODFHanlder discovered from Service.providers?
gerhard
Re: Drop RTF Support?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi Mark,
Mark C. Allman a écrit :
> Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
>
> Swap out RTF with, say, ODF? Sounds great to me.
>
> I'd even volunteer some time to help with development. I seem to
> remember something about Java.... ;-]
Thanks for your offer to help!
However... would that make sense to produce ODF from XSL-FO? There is no
semantic construction at all in FO, whereas there is some in ODF. The
other way around looks much more useful to me; as style informations are
stored using FO, this should be very easy to convert an ODF document
into plain XSL-FO.
Typically the transformation chain:
XML —> XSL-FO —+—> RTF
|
+—> PDF
would be replaced by:
XML —+—> XSL-FO —> PDF
|
+—> ODF
WDYT?
Vincent
Re: Drop RTF Support?
Posted by "Mark C. Allman" <mc...@allmanpc.com>.
Drop RTF with nothing to replace it, e.g., ODF? I'd rather not.
Swap out RTF with, say, ODF? Sounds great to me.
I'd even volunteer some time to help with development. I seem to
remember something about Java.... ;-]
-- Mark C. Allman,
PMP
-- Allman
Professional
Consulting, Inc.
-- 617-947-4263
--
www.allmanpc.com
BusinessMsg -- the
secure, managed,
J2EE/AJAX
Enterprise IM/IC
solution.
On Tue, 2007-07-31 at 14:48 +0200, Vincent Hennebert wrote:
> Hi,
>
> There have been various questions on fop-user recently regarding the RTF
> output of FOP. Personally I�m incapable of helping in this area, and
> also most unwilling to.
>
> Tell me if I�m wrong, but I suspect that in the current team there is
> about one person who could help / modify the code, and who wouldn�t be
> very willing to either.
>
> More and more often people who ask questions regarding RTF are answered
> that going the OpenDocument (or similar XML format) route might be more
> successful. So, I�m wondering if we shouldn�t drop support for RTF in
> the next release.
>
> Not completely, of course, but basically we wouldn�t advertise it, and
> say that RTF support is provided as is, is no longer maintained, and
> that users are on their own when using it. That way they would at least
> be aware of the risks of going that route.
>
> WDYT?
> Vincent
Re: Drop RTF Support?
Posted by Vincent Hennebert <vi...@anyware-tech.com>.
Hi,
Jeremias Maerki a écrit :
> Such a move would have to be well-documented because some people could
> (or probably will anyway) be upset when they upgrade and RTF just stops
> working until they add fop-sandbox.jar. I'm sure there are a lot of
> people perfectly happy with what the RTF handler produces.
>
> I'm not against moving it to the sandbox but I think I'd prefer just
> making the status of the various output formats much more prominent.
Well, I wasn’t meaning that the RTF renderer would be removed from the
Trunk. I just wanted to add some kind of note on the website that RTF is
less supported than other formats (just like txt, after all). Moving it
to the sandbox might be an idea, but if you’re planning on restart
working on it I think we may just leave it as is.
So I’ll stick to rephrasing the website a bit.
Thanks,
Vincent
Re: Drop RTF Support?
Posted by "b.ohnsorg" <b....@freenet.de>.
Jeremias Maerki wrote:
> Such a move would have to be well-documented because some people could
> (or probably will anyway) be upset when they upgrade and RTF just stops
> working until they add fop-sandbox.jar. I'm sure there are a lot of
> people perfectly happy with what the RTF handler produces.
Sorry for being silent all the time after big words 'bout RTF-improvement of mine. Dropping: Bad, Micros~1-Office components aren't dropped even they don't work ;-) Right now I'm really busy with own projects but months ago I started to write a small document 'bout FOP-RTF-problems and sollutions. I'd like to return to this and give RTF a bit a push. I personally rely on RTF export and do it a lot including post-processing with Perl-Regex to get rid off some eeky stuff.
Why not just adding OpenDocument and leave RTF the way it is...?
--
------
http://krachlattenpaul.homelinux.org
Home of Trackbase (1.3.0), VoiceLeadingCalculator (1.2.1) and
the immortal Swear-O-Tron...
Re: Drop RTF Support?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Such a move would have to be well-documented because some people could
(or probably will anyway) be upset when they upgrade and RTF just stops
working until they add fop-sandbox.jar. I'm sure there are a lot of
people perfectly happy with what the RTF handler produces.
I'm not against moving it to the sandbox but I think I'd prefer just
making the status of the various output formats much more prominent.
After all, besides being practically the only RTF maintainer, I'm probably
the only active committer who knows enough about PCL. PCL is also just
minimally built to get decent results. With obligations elsewhere during
the last 14 months I had to reduce in certain areas so RTF got neglected
if not ignored. Even though I don't like RTF at all and would prefer ODF
support, I think it would be a shame to let RTF output drop without any
alternative. My long-awaited holidays start tomorrow (still haven't
finished everything I wanted) but I plan to re-establish RTF support
starting in October when I'm back working on FOP 100%.
Jeremias Maerki
On 31.07.2007 16:07:43 Chris Bowditch wrote:
> Manuel Mall wrote:
>
> <snip/>
>
> >>
> >>Not completely, of course, but basically we wouldn’t advertise it,
> >>and say that RTF support is provided as is, is no longer maintained,
> >>and that users are on their own when using it. That way they would at
> >>least be aware of the risks of going that route.
> >>
> >
> > What about moving RTF to the sandbox? That should signal its
> > incomplete / still in draft / not officially supported status.
>
> I agree with Manuel. I dont think we should just drop it because I think
> there are a lot of people using it. Well thats the impression I get from
> all the questions that are asked about it. Moving it to the sandbox is a
> clear way of saying its unfinished and not supported.
>
> Chris
>
Re: Drop RTF Support?
Posted by Chris Bowditch <bo...@hotmail.com>.
Manuel Mall wrote:
<snip/>
>>
>>Not completely, of course, but basically we wouldn’t advertise it,
>>and say that RTF support is provided as is, is no longer maintained,
>>and that users are on their own when using it. That way they would at
>>least be aware of the risks of going that route.
>>
>
> What about moving RTF to the sandbox? That should signal its
> incomplete / still in draft / not officially supported status.
I agree with Manuel. I dont think we should just drop it because I think
there are a lot of people using it. Well thats the impression I get from
all the questions that are asked about it. Moving it to the sandbox is a
clear way of saying its unfinished and not supported.
Chris
Re: Drop RTF Support?
Posted by Manuel Mall <ma...@apache.org>.
On Tuesday 31 July 2007 20:48, Vincent Hennebert wrote:
> Hi,
>
> There have been various questions on fop-user recently regarding the
> RTF output of FOP. Personally I’m incapable of helping in this area,
> and also most unwilling to.
>
> Tell me if I’m wrong, but I suspect that in the current team there is
> about one person who could help / modify the code, and who wouldn’t
> be very willing to either.
>
> More and more often people who ask questions regarding RTF are
> answered that going the OpenDocument (or similar XML format) route
> might be more successful. So, I’m wondering if we shouldn’t drop
> support for RTF in the next release.
>
> Not completely, of course, but basically we wouldn’t advertise it,
> and say that RTF support is provided as is, is no longer maintained,
> and that users are on their own when using it. That way they would at
> least be aware of the risks of going that route.
>
What about moving RTF to the sandbox? That should signal its
incomplete / still in draft / not officially supported status.
> WDYT?
> Vincent
Manuel