Glen Mazza wrote:
> At any rate, though, I anticipate us bringing in and
> modifying the code over time, rather than keeping it as an
> external JAR.
That is fine, but I hope you and others will give the jar approach a fair
trial. The whole point of the collaboration is to avoid duplication of
effort. I know (better than most) that forks are sometimes unavoidable, but
I hope they will be considered a last resort.
> Related to this is that I moved FOP from the controller-class (in use
> 1998-2004) to the pipeline approach 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
Why do you say this? An org.foray.font.Font is pretty similar in concept to
a java.awt.Font, except that it provides additional services. The FontServer
is needed to keep the various clients separate. (This is important for TTF
subsetting in multi-threaded environments). The whole system should work
fine AFAICT anywhere where java.awt.Font might be used. It should work
equally well with FOP's "pipeline" (pipes cemented with glue) or with
FOray's pipeline (the Unix-ish definition of a pipe with components that are
agnostic about the source of input or the use of output).
> 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 like to think that FOP will eventually switch, not back, but forward to a
componentized model, but think the only way to see that happen is to show it
working in FOray. But really, nothing that I can see in FOrayFont should
require any architectural changes one way or another. If FOP wants or needs
to change its architecture, I don't see it coming as a result of anything in
> 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.
Sorry, I couldn't parse your meaning here at all, unless you are arguing
against changing the architecture back. Again, that shouldn't be necessary.
> 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.
Well, the API issue is separate from the internal architecture issue, which
in turn, is separate from the font system issue. Some of the ugliness that
existed in the code at that time was due to my efforts to change the
internal architecture *without* changing the outer-layer API, which, at the
time, was forbidden. That has changed.
Nevertheless, there is one API issue which FOP will need to consider. A
FontServer instance needs to be created somewhere. FOray accepts one in the
FOraySession constructor, but instantiates one if it is passed null. IMO,
this maximizes flexibility, but if FOP wants to leave its API alone (and I
understand the desire to do so), it can simply instantiate one internally.