Peter B. West wrote:
> I have been exploring the way fonts are handled by Java as
> part of setting up a Java layout engine and renderer. I have
> committed a new class - org.apache.fop.render.awt.fonts - as
> a first cut at a fonts database for this application. I will
> attach the class description to this email.
The last time I checked, there was no way to get to the physical font file
through the awt interface. It is possible that java.awt.font.OpenType can
provide some or all of what is needed for TTF and OT fonts, but I don't know
of a way to handle Type1 embedding at all. This means that you cannot ever
embed the said font, unless you set up a parallel system (similar to the way
FOP handles things now) to find the physical file. Another issue is headless
environments. I once went down the path of trying to figure out how to
register fonts in a headless environment, and frankly don't remember what I
learned. It is probably possible.
There may come a time when the awt system is the way to go, but AFAICT, it
isn't here yet, but I'll be glad to be proven wrong. I don't say this to
discourage you -- if you know how to make it work, that will be a very good
thing. BTW, Hansuli Anderegg has been a frequent advocate of the awt system
for this work.
One important point here is that, even if awt font handling were the correct
*implementation* of font handling to use, there would still be, IMO anyway,
utility in hiding even that fact from the rest of FOP, certainly no harm.
I am taking the next comment out of sequence from Peter's original post,
because it is fundamental to comments earlier in his post, which I will
address below:
> Fonts are inherently renderer specific. It may be that those
No. Font *embedding* is renderer specific. AFAICT, everything else about the
font is the same.
> I have read again the Wiki page on the font subsystem in the
> light of my current work with Java fonts. I'm afraid that I
> am still convinced that font handling is properly the
> preserve of the renderers. The layout engine needs only the
> font metrics, even for Java-based layout. As far as layout
> is concerned, the glyphs could all be Wingdings, as long as
> the metrics are right. The other required information is
> that relating to font selection, as discussed above. The
> logical home for font selection information is the renderer.
It is a non sequiter to say that layout needs only font metrics (which is
true), and therefore the logical home for font selection information is the
renderer.
One thing that may be confusing you is the distinction that awt makes
between java.awt.Font and java.awt.FontMetrics. There is only one
constructor for FontMetrics:
protected FontMetrics(Font font)
Therefore, at a *logical* level, there is a one-to-one relationship between
the two. At the physical file level there is also a strict one-to-one
relationship between the two, when the metrics are separated at all. There
is no need that I can see for FOP to treat the concepts of Font and
FontMetric as two different things. Once a font object is stored in the
FOTree that object should be able to return any metrics information about
that font.
> This is not to say that, once a clean fonts interface has
> been developed and implemented in all of the renderers, a
> further level of abstraction cannot be applied to bring all
> of the information under one umbrella.
I have always found that cleaning up the abstraction levels and interfaces
(i.e. getting the big-picture stuff straight first) makes getting the
details right easier as well, by isolating them. However, I won't quibble
with you.
> However, consider the problem of creating a new renderer.
> Fonts are inherently renderer specific. It may be that those
> fonts are shared between more that one renderer, but that
> fact is incidental to, e.g., the common ancestry of PS and
> PDF. Which is more sensible - writing a renderer's font
Again, the underlying font is the same whether you are rendering to PDF,
Postscript, or anything else. Only the embedding would change. Please let me
know if I have missed something.
> PDF. Which is more sensible - writing a renderer's font
> handling to a common renderer font interface as an integral
> part of the renderer implementation, or discovering the fonts
> quirks of this particular renderer and adding them separately
> to a central font handler/registry?
This is a very good question, one that I have already pondered at some
length. Again, I am thinking only of the process of embedding here. The
first principle that I look to is that in either case, font embedding should
be factored out of FOP. There is nothing about either font-handling or the
creation of PDF files (or PostScript, or PCL, or whatever) that is
FOP-specific. Assuming this, I would lean heavily toward placing the
font-embedding logic in the output-specific library (i.e., put the PDF
embedding logic into the pdf output library, instead of fonts), because not
everything wanting Font support needs the ability to embed a font in PDF,
while almost certainly anything creating PDF will want to embed fonts.
Victor Mote
