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