Re: Review of the FOrayFont patch and FOrayFont itself
On 22.12.2005 22:47:24 Vincent Hennebert wrote: > Damn :-( Yes. :-( > Looks like some more work is needed. Problem is that it does no longer > depend only on me. > > Basically I agree with reasons 1. and 3. I don't really get the second > one, perhaps because I don't have a broad view of the problem. However > the distinction between system fonts and free-standing fonts looks clear > to me: the former are fonts handled by the Java awt system, for which > some informations may be lacking (e.g., embedding); the latter are those > for which a font file is available, and are handled externally. I know point 2 is more complex than what I could describe in just a few sentences. I seem to have failed to explain my views here before when showing them to Victor. Maybe I'm off the road, too. Anyway, thanks for explaining the way the two font groups are meant to be understood. Not that I agree with them for some detailed technical reasons. But we can agree to disagree which does not make your effort worth less in my opinion. It's not a MUST, it's about the ideal approach I see. It can always be improved in time. > Anyway, I think that there is a need for reviewing all the font stuff. > Some issues about font baselines, character selection, glyph > substitution and so on haven't been handled yet, or only partially. Yes, however, none of them is a VIP (very important point). :-) If you see the latest problems with TTFReader/PFMReader it becomes apparent the user-friendlyness is such a VIP. Granted, these are very basic problems, but people tend to run into them. > I was hoping to see FOrayFont integrated as is in the trunk in a first > step, before starting to improve the font system and integrate other > functionalities. This looks like it is impossible. That was my idea, too. But while reviewing, just too many negative points showed up for me to be comfortable with integrating this just now in the main dev line. It's not impossible. It needs some additional work and then we'll look at it again. I'd love to help more but currently, I can't. This font stuff is very important to me. And not only because it's the one topic that got me started with FOP 5 years ago. > This may be useful anyway to create a branch for the patch, so that > other people can have a look at it. I made the patch against revision > 356368. I let you decide. We can do that, but we'll need some additional feedback from the other committers. I don't want to decide on that alone. > I'll spend some time now studying all the needs of a font sub-system for > a FO processor: on the layout side, regarding the different font types, > and the various renderers. I'll collect all what has already been said > on this list; I'll study the font formats in more details. I think I'll > put all that on a Wiki page, but rather perhaps in the aXSL area, don't > know yet. That would be appreciated. You can, of course, use the FOP Wiki if you like. > This will require time, I have many things to learn; so don't expect any > concrete result before... long. Any comment or opinion is welcome. Thank you very much for your perseverance. I'll try to support you as much as I can. Maybe I can allocate some time to this in a few weeks from now. Jeremias Maerki
Re: Review of the FOrayFont patch and FOrayFont itself
Damn :-( Looks like some more work is needed. Problem is that it does no longer depend only on me. Basically I agree with reasons 1. and 3. I don't really get the second one, perhaps because I don't have a broad view of the problem. However the distinction between system fonts and free-standing fonts looks clear to me: the former are fonts handled by the Java awt system, for which some informations may be lacking (e.g., embedding); the latter are those for which a font file is available, and are handled externally. Anyway, I think that there is a need for reviewing all the font stuff. Some issues about font baselines, character selection, glyph substitution and so on haven't been handled yet, or only partially. I was hoping to see FOrayFont integrated as is in the trunk in a first step, before starting to improve the font system and integrate other functionalities. This looks like it is impossible. This may be useful anyway to create a branch for the patch, so that other people can have a look at it. I made the patch against revision 356368. I let you decide. I'll spend some time now studying all the needs of a font sub-system for a FO processor: on the layout side, regarding the different font types, and the various renderers. I'll collect all what has already been said on this list; I'll study the font formats in more details. I think I'll put all that on a Wiki page, but rather perhaps in the aXSL area, don't know yet. This will require time, I have many things to learn; so don't expect any concrete result before... long. Any comment or opinion is welcome. Vincent Jeremias Maerki a écrit : I've applied Vincent's patch locally and went through the code. I had to do several modifications because I've recently changed a few things in the Trunk which broke Vincent's patch. I managed to get it to work without bigger problems. However, I must say that I currently could not vote +1 to apply the patch. Let me show why: The main reason right now is lack of time. This topic will eat quite some time as it turns out. There are several points I would want to have improved first: 1. As I suggested earlier, having a mandatory font configuration is not acceptable IMO. The whole thing needs to work out-of-the-box for the set of fonts that can be considered present for each target format (Base 14 fonts for PDF and PS, AWT fonts for Java2D output etc.). To make this work, the AFM files for the Base 14 fonts would be placed in the JAR file. However, while going through FOray's source code I found that the font loading code currently needs a RandomAccessFile which means that either the file has to be first copied to the file system, a new implementation of the RandomInput interface would have to be written for access on an in-memory copy on the AFM files or the code has to be rewritten to work on a simple InputStream. 2. I'm a little disappointed that Victor did not follow my ideas of font sources, but I guess it was easier for him this way. So I can understand. With my approach, the FontServer would hold a set of font sources each of which provides access to a set of fonts (i.e. the AWT fonts, the Base14 fonts, a directory of Type1 fonts etc.). The client application would tell the FontServer (via the FontConsumer I guess) which font sources are acceptable. For each font source an URI could be defined that identifies it so that interoperability and extensibility are preserved. ATM, there are only the two somewhat artificial groups: free standing fonts and system fonts. I don't think this is flexible enough on the long run. Anyway, the current aXSL Font API feels a little strange still. But some of that I've already pointed out to Victor at an earlier opportunity. The way the used fonts are stored is also a suspect point to me since it bears the possibility of a memory-leak if a FontConsumer is not properly unregistered in case of an exception. Currently, the FontConsumer is not released at all. This would have to be looked at closely. 3. The configuration file is too complicated in my opinion (especially the mapping part). It should be much easier. The complexity somewhat kills the benefit of loading fonts directly, and not via XML font metrics files. I would really, really like to have the possibility to specify a directory and all fonts are all automatically made available. People already have problems all the time to get their fonts working. I would not like to see it getting even more complicated. After all, you don't have to write a complex configuration file when you install a font in Windows, for example. I agree that there can be sections in the config file to specify font substitutions but the default font names should be available automatically. While testing I had to specify absolute paths to get the font config working quickly. In the short time, I was looking at it I didn't manage to get it to work otherwise. In the end, I have to look at the cost/benefit ratio: + ToUnicode fix (also availab
Review of the FOrayFont patch and FOrayFont itself
I've applied Vincent's patch locally and went through the code. I had to do several modifications because I've recently changed a few things in the Trunk which broke Vincent's patch. I managed to get it to work without bigger problems. However, I must say that I currently could not vote +1 to apply the patch. Let me show why: The main reason right now is lack of time. This topic will eat quite some time as it turns out. There are several points I would want to have improved first: 1. As I suggested earlier, having a mandatory font configuration is not acceptable IMO. The whole thing needs to work out-of-the-box for the set of fonts that can be considered present for each target format (Base 14 fonts for PDF and PS, AWT fonts for Java2D output etc.). To make this work, the AFM files for the Base 14 fonts would be placed in the JAR file. However, while going through FOray's source code I found that the font loading code currently needs a RandomAccessFile which means that either the file has to be first copied to the file system, a new implementation of the RandomInput interface would have to be written for access on an in-memory copy on the AFM files or the code has to be rewritten to work on a simple InputStream. 2. I'm a little disappointed that Victor did not follow my ideas of font sources, but I guess it was easier for him this way. So I can understand. With my approach, the FontServer would hold a set of font sources each of which provides access to a set of fonts (i.e. the AWT fonts, the Base14 fonts, a directory of Type1 fonts etc.). The client application would tell the FontServer (via the FontConsumer I guess) which font sources are acceptable. For each font source an URI could be defined that identifies it so that interoperability and extensibility are preserved. ATM, there are only the two somewhat artificial groups: free standing fonts and system fonts. I don't think this is flexible enough on the long run. Anyway, the current aXSL Font API feels a little strange still. But some of that I've already pointed out to Victor at an earlier opportunity. The way the used fonts are stored is also a suspect point to me since it bears the possibility of a memory-leak if a FontConsumer is not properly unregistered in case of an exception. Currently, the FontConsumer is not released at all. This would have to be looked at closely. 3. The configuration file is too complicated in my opinion (especially the mapping part). It should be much easier. The complexity somewhat kills the benefit of loading fonts directly, and not via XML font metrics files. I would really, really like to have the possibility to specify a directory and all fonts are all automatically made available. People already have problems all the time to get their fonts working. I would not like to see it getting even more complicated. After all, you don't have to write a complex configuration file when you install a font in Windows, for example. I agree that there can be sections in the config file to specify font substitutions but the default font names should be available automatically. While testing I had to specify absolute paths to get the font config working quickly. In the short time, I was looking at it I didn't manage to get it to work otherwise. In the end, I have to look at the cost/benefit ratio: + ToUnicode fix (also available through Adam's patch) + Getting rid of the need to generated XML font metric files o Change in config format (documentation etc.) - Config format too complicated - Config is mandatory - Extensibility not easily visible in the API. Many output specific aspects are in general interfaces. How would AFP fonts be handled? - Two projects will depend on the font package. That means a restriction on freedom. Changes cannot easily be made. - Lack of time on my side to push the font integration right now. Not much left in the end, I'm afraid. I know that with my comments above I'm criticising a lot but that doesn't mean I'm not willing to invest time here and in FOray/aXSL to help improve things. It's just that currently I'm not able to invest the necessary time right now. I also know that it's bad for Vincent because of all the time he has spent so far. We can talk about putting the changes into a branch, but I don't feel comfortable saying +1 for inclusion in the Trunk right now. Another approach could be to pack our current font support into a aXSL font implementation so the transition to FOrayFont would come easier later, but IMHO it would still make some changes necessary in aXSL. I don't agree with some of the patterns used there. If there's another champion among the FOP committers to take the lead here, the situation could also look different. Other opinions? Jeremias Maerki