I haven't researched fonts in general so I can't comment on its value or quality. However, Victor's coding has shown itself to be pretty solid and robust in the past. *What* Victor codes is often not my preference, but the *way* he codes what he does is quite good. In general, if I had a mission-critical system to build I would be comfortable relying on him to build it.

At any rate, though, I anticipate us bringing in and modifying the code over time, rather than keeping it as an external JAR.

Related to this is that I moved FOP from the controller-class (in use 1998-2004) to the pipeline approach[1] early last year, and still recommend that architecture. However, I suspect the font code will be expecting a controller-class architecture to work. Given that most committers have been comfortable with the controller-class approach in the past, I would be OK with it if we wanted to switch back--I can't spend as much time anymore on FOP anyway. I remain satisfied that the proof-of-concept worked but we have users to satisfy here... ;-)

I do have a caution to offer though: If the goal is to be rewarded for one's efforts on FOP, make sure the architectural decisions are done so that 18 months, 24 months down the road FOP will have a 90% market share, even if it means there will be grumbling on the mailing lists for the initial few months because FOP 0.20.5 is incompatible with FOP 1.0. I personally am strong-kneed enough to handle the grumbling with the knowledge that FOP will be ultimately very successful. Indeed, I take it for granted that if you want a work-of-art system that puts the competition to shame two years down the road, you have to make the unpleasant architectural changes now to put FOP's past behind it. For practical reasons though, we may end up needing to restore some of the API back such as Driver. But if the team does not think long-term, and just reacts to every individual ML complaint by adding to the API, FOP will become unmaintainable and start to degrade. I was around in late 2003 when FOP 1.0 had all the API's of the past--it also went down to three active committers at that time--Victor, Joerg, and myself. Too much to maintain, then people get turned off from the project, and, long-term, users on the ML get confused, given the multiple ways to do the same thing.


[1] http://marc.theaimsgroup.com/?l=fop-dev&m=106246324305040&w=2

J.Pietschmann wrote:

Vincent Hennebert wrote:

Sorry to insist, but what is your final decision? A quick summary of the thread gives:
- Jeremias +1
- Simon +1
- Glen +0
The FOray+aXSL stuff would be used in the form of a jar file put in the lib directory; FOray's avalon loggers would be wrapped into a JCL adapter for now.

I'm somewhat uneasy with having an important if not essential
subsystem developed outside (unless already widely used elsewhere),
but I certainly wont veto anything which advances the project.



Reply via email to