Frustration With FOP

[W. Eliot Kimber]

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, [EMAIL PROTECTED]
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]