Hi all,

Sorry for the long post, but I think this is an important one.

I would like to have your feelings about the FOrayFont integration.
Since I started to work on that (in July 2005), things have quite
evolved and I'm starting to doubt that integrating FOrayFont really is a
good thing for Fop.

I've already discussed with some of you about this whole issue, but I
think it might be worth summarizing the points, and making everyone
aware of it. Because I've the feeling that whatever decision we make,
this will be a difficult one.

First, some progress informations about the integration: the PDF
renderer works now with FOrayFont, and seems to run well. The other
renderers are still to be adapted. There shouldn't be too much work for
the Java2D-based ones, a bit more for the Postscript Renderer, and also
for PCL and AFP (I can't evaluate how much there is to do for those ones
as I know nothing about those formats).
I estimate to about 5 days the amount of work to have a compilable
thing. There should be no loss of feature; there is a known problem with
the Postscript renderer (no way to know which fonts are used for a given
page, so we have to embed all of the configured fonts in the header),
but Jeremias is working on a two-pass system thanks to which this
problem should be solved soon.

For those who are not familiar with the FOrayFont architecture, here's a
quick presentation: there is a separate project called aXSL [1] (also
maintained by Victor) whose purpose is to define a standard API for
several modules related to XSL-FO. The one we're interested in is
aXSL-font, but there are also modules for dealing with graphics,
manipulating the FO tree, the area tree, etc.
The goal is to have standard interfaces shared by XSL-FO
implementations. Provided that, of course, there are more than one
implementation which implement aXSL.
So FOrayFont is a particular implementation of aXSL-font. If Fop were
using FOrayFont there would actually be almost only aXSL calls in the
code.

[1] http://www.axsl.org/

Now, let me enumerate the pros and cons of the adaptation of FOrayFont
to Fop:

Cons:
- After Bertrand's recent work on OTF support the existing font library
  is not far from being as feature-complete as FOrayFont:
  - ToUnicode support is now available;
  - it seems easy to remove the XML metrics generation step (actually
    Jeremias told me he had already done it on his working copy)
- the old font support would have to be kept for use by Batik (PS & PDF
  transcoders) as the Batik people have strong feelings against external
  dependencies
- FOrayFont introduces a new font-config file which would disturb users
  (although I think it is better and more flexible than the current one)
- FOrayFont is mainly a one-man-show and it's not very good for Fop to
  have such a dependency. And as this is primarily Victor's baby we
  can't just come in and ask for write access to the code or whatever.
  We must first show that our point of view is adequate to Victor's one.
- However, it seems like we have difficulties understanding each other:
  each time I propose a change on the dev list, that triggers a lengthy
  discussion where we both try to explain our own point of vue and
  understand the other one, without even finally succeeding I think.
  There is whatever cultural gap + foreign language issue that hinders
  communication.
- As a consequence, proposing changes on the aXSL/FOray area to better
  suit our needs will require twice as much time and energy as doing
  them on our own side.
- And given that the API isn't perfect yet, I'm a bit afraid of going
  that route.
  One missing major feature for example is the ability to cache
  informations about fonts and retrieve them later; this is necessary
  for the XML area tree output or the CachedRenderPagesModel. There is
  simply no means in the API to get a font's identifier, in order to
  retrieve it later without having to re-launch the whole resolution
  process.
- during the past year, growing technical disagreements have appeared;
  if we keep working together we might end up with having a thing that
  satisfies neither of us, because of the too many compromises we would
  have to do. That ranges from programming practices to API design
  decisions.
- As far as I know, FOray has never been used in production yet, and it
  may be unstable. There are currently not many testcases and, well,
  it's already not very funny to write testcases for one's own code, if
  I have to write testcases for others...

Now for the pros:
- This would be unfortunate to break the last bridge between Victor and
  Fop.
- I've myself already done quite a bit of work on FOrayFont, which would
  be basically lost.
- Despite existing problems Victor brought quite a number of
  improvements to the font library, which would have to be re-done. And
  he started from the 0.20.5 code, like we would if we were to go our
  own way (tell me if I'm wrong, but I don't think the font code changed
  a lot during the re-design).


I see the following ways we could go:
- finish the FOrayFont adaptation, along with bringing to FOray the few
  improvements I have in mind, and see how this is going.
- fork aXSL and FOrayFont and modify them to suit our needs. There
  shouldn't be any major licensing problem as Victor has always said he
  would make no difficulty donating his code back to Fop.
  This would always be possible to contribute our changes back to
  aXSL/FOray, but we all know how forks evolve in the open-source
  world...
- abandon the aXSL/FOrayFont way and re-start from the current font
  library.


So, I'd like to have your opinions on that issue. There's no hurry, take
your time to make your mind about that. I've plenty of other things to
work on during that time ;-)


Thanks,
Vincent

Reply via email to