Review of the FOrayFont patch and FOrayFont itself

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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

Re: Review of the FOrayFont patch and FOrayFont itself

[Jeremias Maerki <de...@jeremias-maerki.ch>]

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.

<snip/>


Jeremias Maerki

Re: Review of the FOrayFont patch and FOrayFont itself

[Vincent Hennebert <vi...@enseeiht.fr>]

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