xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Foray's font subsystem for Fop
Date Tue, 14 Jun 2005 08:09:40 GMT
I'm sorry, that I'm so late. I'm currently drowning in dozens of little
things I need to attend to.

On 13.06.2005 18:47:09 Victor Mote wrote:
> Vincent Hennebert wrote:
> > If you decide not to do it, well, no matter, I'll find 
> > another thing to do ;-)
> 
> Since I am in a later time zone than almost anyone, I suppose that everyone
> has had a chance to respond to this by now. Hopefully I am wrong.

Yes, you are. I've seen the thread but felt I'd have to approach this
carefully.

To state my opinion on this matter:
I would like to see Vincent integrating FOray-Font into FOP. There has
been some work on fonts compared to the FOP maintenance branch but
Victor has invested more time in FOray-Font. Victor's font subsystem is
now technically more advanced than what we have. The most interesting
feature is the fact that you don't have to create that bloody font
metrics file anymore. When that is eventually coupled with automatic
font registration then it'll be a killer feature. I consider this one of
the more important tasks to improve user-friendliness. Of course, the
same functionality could also be done within FOP but why duplicate the
effort? I'm sure there are still a few things that would need to be
polished inside FOray-Font but if it helps us taking a step forward then
I'm all for it. But that's obviously my technical side speaking.

Ideally, a font engine that is shared between two projects should be in
a more or less neutral place write-accessible by both parties but as
we've seen now there are personal dissonances. The problem comes up if
Glen starts to veto against using Victor's work, of if Victor can't or
won't support our wishes anymore. The latter could be a real problem if
we switch to FOray-Font as it is a crucial part in the puzzle. But
Victor already provided a potential way to improve that situation: aXSL.
If we converted our current font engine to implement the aXSL interface,
we can easily switch. The downsides are the need to maintain
compatibility with aXSL as it advances and aXSL has first to show that
it is capable of handling multiple implementations.

Looking at this from a distance:
1. From a technical perspective, we should work together, if only to
avoid being silly by duplicating work.
2. From a psychological perspective, I don't think the two projects will
ever get along.

That said, I think Victor and I get along together pretty well. He
doesn't even mind discussing stuff with me which is a good sign. Too bad
I got so little time discussing some really interesting stuff with him,
but I have to concentrate on the layout engine ATM. But there are so
many broken glasses on both sides that I doubt we find a way of working
together.

> If the FOP developers change their minds and decide to work with you, good.
> If not, please consider posting a message to the FOray mailing list telling
> me more about what you are trying to accomplish, and I'll be glad to offer
> some suggestions if I can. FOray's design not only makes it easier to use
> FOray code in FOP, but it makes it easier to use FOP code in FOray.

That sounds like a suggestion for collaboration to me. Give and take. I
hope I'm right, Victor. You know I would really like to work together
with you again. It's simply that I'm afraid of the old feelings come
back (from whatever side) and the two project teams break off with each
other again leaving a mess behind.

The two reasons that make me hesitant to really put energy into
reestablishing a mode of collaboration is the high risk of failure,
especially given the immediate bad energies that bubbled up following
Vincent's proposal, and the fact that I have the impression that FOray
is a one-man-show and there's a risk for FOP depending on such a thing.

> And
> FOray has no internal political issues that prevent it from using
> compatibly-licensed code developed elsewhere.

Yes, but see my second reason just above.


Jeremias Maerki


Mime
View raw message