xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: Foray's font subsystem for Fop
Date Tue, 14 Jun 2005 19:00:36 GMT

On 14.06.2005 17:59:03 Victor Mote wrote:
> Jeremias Maerki wrote:
> > Ok, but this assumes that you work in concert with AWT's font 
> > subsystem.
> > If we talk about the font subsystem for PDF and PS we have 
> > all liberties we want. If we can give the FO processor a 
> > directory and it makes all the fonts in this directory 
> > available for FO processing then I am where I would like to 
> > be. Of course, there will be some additional topic such as 
> This is very doable (although I would not have thought to call it
> auto-registration). Foray does not rely on anything in the font
> configuration to tell it what kind of font file it is working on -- in other
> words, it parses enough of each file already to create instances of the
> correct font subclass. It would not be hard to write a method that opens a
> directory and creates font instances for each file in that directory. Except
> ...
> > font substitution and embedding control, but if we can make 
> ... and even font naming. One of the things that the configuration file does
> is provide (at least potentially) an unambiguous and cross-platform way of
> declaring the relationships between fonts in various families and the
> mapping between what they are called in an FO document and how they are
> found in the system.

That's actually what I meant by font substitution. It's good we talked
about it. ;-) 

> > the font registration a no-brainer for at least 60% of the 
> > people we've accomplished a lot. The Java2D/AWT renderer is a 
> > different story. There we have to work with what we are 
> > given. I really wonder if Peter will really stay with the 
> > 100% AWT approach till the end.
> Most people will want to point the auto-registration to C:\WINDOWS\FONTS.
> Mine has 581 files in it, each of which would have to be opened and
> partially parsed. I actually use no more than 10-15 for FO work. I think
> this might actually open up a bunch of potentially ugly support issues, and
> I would think twice about it. Nevertheless, it can be done.

Not necessarily. I thought about that. We would have to create some sort
of font cache file which holds the most important info to avoid parsing
every font before it's really used. I've seen that even the old Acrobat
Reader 4.05 on Linux did something like that.

> As far as Peter's ideas in this area, I want to spend more time on them.
> There is a great divide in FOrayFont between what we call FreeStandingFont
> (those read from disk) and SystemFont (the AWT fonts). Ideally it would be
> nice for those to be merged. Since an AWT font can be created from a font on
> disk, if those metrics are suitable for layout, then the disk font can be
> used for embedding (this can't be done with AWT fonts returned by the java
> runtime, because it doesn't tell you where the physical file is or what are
> its contents).

And the reported metrics seem to be different!

> That whole idea deserves more thought and experimentation,
> and I haven't had time to work on the font system since October.

Absolutely. It would be great if it could be made to work but I
seriously doubt it. At any rate I wish Peter the best of luck with his
approach. I hope he'll be a happy customer of our Graphics2D
implementations when they are separated in the XML Graphics Commons area.

Jeremias Maerki

View raw message