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  (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.  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