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 "W. Eliot Kimber" <el...@isogen.com> on 2002/11/16 16:51:13 UTC
Frustration With FOP
I feel a need to say something about my frustration with FOP, because I
think it's a potential issue for the XSL FO world in general and it
concerns me, especially as a person who's working very hard to try to
advance the acceptance and use of FO, both through educating potential
users and working with the various implementations to identify flaws and
suggest improvements.
First, let me be clear that FOP as a project is a very good thing: the
world absolutely needs a solid open-source implementation of XSL FO. I
know that the FOP volunteers are working very hard and have put in an
amazing amount of effort on the development achievements to date. I know
how hard it is to implement page composition at all, much less in the
context of a highly generalized scheme like XSL FO.
My frustration stems from the fact that FOP, as good as it is, is simply
not ready for general use--it implements too few features of FO and has
too many implementation bugs to be considered a candidate for any sort
of production use except in the most constrained use cases.
This means, for example, that I cannot report my experience with how FO
implements a particular feature for the simple reason that FOP is unable
to process most of my samples *at all*. For example, I just downloaded
the latest stable release and tried to run it against a sample I have
that exercises a wide range of table rendering options. Because FOP
doesn't implement support for percentages for lengths on blocks (the
message I get indicates that it doesn't know how to deal with "100%" as
a value for inline-progression-dimension, which must be coming from
"width="100%" on my tables), it can't render these table samples at all.
Because my focus as an integrator is on building production systems for
my customers, I can't justify building test cases that will work within
the severe constraints currently imposed by FOP. This frustrates me.
My frustration is not that FOP can't do this stuff--it is still in early
development--but that the FOP documentation doesn't make it clear that
it can't do this stuff. If one reads the documentation, including the
limitations, it would appear that FOP implements almost everything in
FO--the list of features listed as explicitly not supported is very
short. But my tests, and a look at the FOP to-dos, make it clear that
FOP is much more limited. This leads to a serious mismatch between
expectations and reality.
My fear, already borne out by some personal experience, is that FOP will
give people a bad first impression of XSL FO, making them think that FO
is much more limited than it is. We've already seen a number of posts
to the various FO-related forums where people have confused FOP and
XSL-FO, thinking that a limitation in the current version of FOP is a
limitation in XSL-FO generally.
I really don't like having to say "I haven't tried X with FOP" because
it makes it sound like I have something against FOP, which I don't. It's
simply a fact that it's still at an early point in its development.
Thus, I would like to urge the FOP team to be more clear about the
current limitations in FOP--list every property value and required
behavior that isn't yet implemented. Also, be clear that, at its current
level of development, FOP is not suited for production use. It's fine
for experimentation and it's fine if you can live within the constraints
it imposes, but it is not yet a general-use FO implementation (that is,
an implementation that is all or mostly plug compatible with the other
available implementations). I think this would go a long way toward
avoiding the mismatch between expectation and experience that can cause
people to get a bad first impression of XSL FO.
Or said another way: I should not have to explain to any of my customers
why FOP is not yet a candidate FO implementation for them--that should
be clear from the FOP site. When that status changes, I will be the
first to let my customers and prospects know, because I know they would
all like to have one more option, one that has no up-front license cost
[which is not the same as saying that FOP is free--there are no free
production solutions, only solutions with upfront licenses costs and
solutions without; but there is always a cost to implementing any tool
set for production use and usually the license cost is the least part of
it.] For example, we have integrated the Apache Lucene full-text engine
in several projects now. I would love to be able to do the same with FOP.
Cheers,
Eliot
--
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Frustration With FOP
Posted by Oleg Tkachenko <ol...@multiconn.com>.
Nikolai Grigoriev wrote:
> If you feel that XEP's validation stylesheet may help - at least
> as a source of inspiration to write your Schematron schema -
> please feel free to use it. The stylesheet is com/renderx/xep/folint.xsl
> inside XEP's Jar file. We plan to make it a public resource, as soon
> as we find spare time to present it on our website.
Thank you, Nikolai! I'll consider it, why not, at least XEP and FOP will have
the same validation behaviour. But our nonimplemented stuff requires
modifications of the xsl.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Frustration With FOP
Posted by Nikolai Grigoriev <gr...@renderx.com>.
Oleg,
> As afaik xsl-fo schematron schema doesn't exist yet (XEP3 uses
> schematron-like xsl for validation) I'm trying to develop such one.
If you feel that XEP's validation stylesheet may help - at least
as a source of inspiration to write your Schematron schema -
please feel free to use it. The stylesheet is com/renderx/xep/folint.xsl
inside XEP's Jar file. We plan to make it a public resource, as soon
as we find spare time to present it on our website.
Regards,
Nikolai Grigoriev
RenderX
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Frustration With FOP
Posted by Oleg Tkachenko <ol...@multiconn.com>.
W. Eliot Kimber wrote:
> I feel a need to say something about my frustration with FOP, because I
> think it's a potential issue for the XSL FO world in general and it
> concerns me, especially as a person who's working very hard to try to
> advance the acceptance and use of FO, both through educating potential
> users and working with the various implementations to identify flaws and
> suggest improvements.
I'm personally very appreciate what are you doing for xsl-fo, Eliot and I
understand your frustration, but you see, we are rather small team and we do
our best. Unfortunately FOP doesn't have such a support from software giants
like, for example, xalan project have so our resources are very limited.
> My fear, already borne out by some personal experience, is that FOP will
> give people a bad first impression of XSL FO, making them think that FO
> is much more limited than it is. We've already seen a number of posts
> to the various FO-related forums where people have confused FOP and
> XSL-FO, thinking that a limitation in the current version of FOP is a
> limitation in XSL-FO generally.
Well, seems to me your opinion is a good argument for input validation module
I was talked about recently. We desperately need a module at the input to
report validation errors, unimplemented warnings etc in a human readable form.
dtd and schema validation doesn't fit the needs, but schematron schema fits
perfectly. As afaik xsl-fo schematron schema doesn't exist yet (XEP3 uses
schematron-like xsl for validation) I'm trying to develop such one. So it's a
matter of time.
+ documentation, which is updated already.
--
Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Forrest updates
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Keiron Liddle wrote (on about 11-19, in a different thread):
>
>
>>Currently the document updating process is manual (but a lot easier than
>>before).
>>Now that current cvs fop can handle the documents a lot better I will do
>>an update once the content is improved.
>>
>>So keep the updates coming and other things like fo examples are always
>>welcome.
>
>
> Is Forrest ready to handle the automatic updating? If so, is there anything
> I can do to help get that process working for FOP? I'm still chasing the
> idea that if we can make it almost as easy & immediate to update the doc as
> it is to answer the mailing lists, we might be able to eliminate some of the
> mailing list traffic.
And if it is not automatic, an explanation of the easier than before
manual process would be useful.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Forrest updates
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-11-25 at 23:52, Victor Mote wrote:
> Keiron Liddle wrote (on about 11-19, in a different thread):
>
> > Currently the document updating process is manual (but a lot easier than
> > before).
> > Now that current cvs fop can handle the documents a lot better I will do
> > an update once the content is improved.
> >
> > So keep the updates coming and other things like fo examples are always
> > welcome.
>
> Is Forrest ready to handle the automatic updating?
Not yet, but they are working on it. :)
If so, is there anything
> I can do to help get that process working for FOP?
There are still more docs to be converted across.
I'm still chasing the
> idea that if we can make it almost as easy & immediate to update the doc as
> it is to answer the mailing lists, we might be able to eliminate some of the
> mailing list traffic.
>
> Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Forrest updates
Posted by Victor Mote <vi...@outfitr.com>.
Keiron Liddle wrote (on about 11-19, in a different thread):
> Currently the document updating process is manual (but a lot easier than
> before).
> Now that current cvs fop can handle the documents a lot better I will do
> an update once the content is improved.
>
> So keep the updates coming and other things like fo examples are always
> welcome.
Is Forrest ready to handle the automatic updating? If so, is there anything
I can do to help get that process working for FOP? I'm still chasing the
idea that if we can make it almost as easy & immediate to update the doc as
it is to answer the mailing lists, we might be able to eliminate some of the
mailing list traffic.
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Frustration With FOP
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Sat, 2002-11-16 at 18:55, Victor Mote wrote:
> Fair enough. I submitted and Keiron committed to the CVS repository this
> past week a document that attempts to do a better job of this. It combines
> the "implemented" and "limitations" pages with a complete list of the
> objects and properties in the standard. It has a place to list comments. I
> am not sure what the cycle is for updating our web site from the CVS docs
> right now, but I think that document will be visible after the next update.
> The truth is that this document will need to be heavily updated to give the
> complete picture, but I think it is a step in the right direction, and gives
> us a place to pull this information together. I encourage you to look for it
> on the FOP web site(entitled "Compliance"), and then help us get it cleaned
> up. If you don't want to download & change the CVS, send your comments to me
> & I'll work on getting them into the doc.
>
> Some of our most valuable developers have invested quite a bit into getting
> the documentation system more automated (using Apache Forrest). That is
> starting to bear fruit, but the truth is that our doc content has gotten a
> bit backed up while that effort was underway. If you have an interest in
> helping us get the doc up to speed, then you jumped in a good time.
Currently the document updating process is manual (but a lot easier than
before).
Now that current cvs fop can handle the documents a lot better I will do
an update once the content is improved.
So keep the updates coming and other things like fo examples are always
welcome.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: Frustration With FOP
Posted by Victor Mote <vi...@outfitr.com>.
W. Eliot Kimber wrote:
> My frustration stems from the fact that FOP, as good as it is, is simply
> not ready for general use--it implements too few features of FO and has
> too many implementation bugs to be considered a candidate for any sort
> of production use except in the most constrained use cases.
The first part of this statement is probably true, the second seems biased
toward your personal experiences. I think there are quite a few places where
FOP is used in a production environment.
> My frustration is not that FOP can't do this stuff--it is still in early
> development--but that the FOP documentation doesn't make it clear that
> it can't do this stuff. If one reads the documentation, including the
> limitations, it would appear that FOP implements almost everything in
> FO--the list of features listed as explicitly not supported is very
> short. But my tests, and a look at the FOP to-dos, make it clear that
> FOP is much more limited. This leads to a serious mismatch between
> expectations and reality.
Fair enough. I submitted and Keiron committed to the CVS repository this
past week a document that attempts to do a better job of this. It combines
the "implemented" and "limitations" pages with a complete list of the
objects and properties in the standard. It has a place to list comments. I
am not sure what the cycle is for updating our web site from the CVS docs
right now, but I think that document will be visible after the next update.
The truth is that this document will need to be heavily updated to give the
complete picture, but I think it is a step in the right direction, and gives
us a place to pull this information together. I encourage you to look for it
on the FOP web site(entitled "Compliance"), and then help us get it cleaned
up. If you don't want to download & change the CVS, send your comments to me
& I'll work on getting them into the doc.
Some of our most valuable developers have invested quite a bit into getting
the documentation system more automated (using Apache Forrest). That is
starting to bear fruit, but the truth is that our doc content has gotten a
bit backed up while that effort was underway. If you have an interest in
helping us get the doc up to speed, then you jumped in a good time.
> Thus, I would like to urge the FOP team to be more clear about the
> current limitations in FOP--list every property value and required
> behavior that isn't yet implemented. Also, be clear that, at its current
> level of development, FOP is not suited for production use. It's fine
I agree with the clarity part, but the judgment call about production use
should be left to the user.
Victor Mote (mailto:vic@outfitr.com)
Enterprise Outfitters (www.outfitr.com)
2025 Eddington Way
Colorado Springs, Colorado 80916
Voice 719-622-0650, Fax 720-293-0044
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org