Victor Mote wrote:
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.

I don't know; I'm new to Java font handling myself. Another disclaimer; I haven't considered the issue of embedding. That said, I don't see a way to get to a physical font.

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.

What I'm exploring is the possibility of going in the opposite direction. That is, using the Interfaces and Classes of java text layout as a model for FOP layout, even if the implementation is FOP specific. That way, when the Java model *is* adequate for FOP's use, it is a trivial matter. The 2D model of text layout seems very powerful.

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

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)

FontMetrics *seems* to have been bypassed in the latest font handling. The methods that are being used in the 2D tutorials focus on LineMetrics, i.e. the metrics of particular pieces of text. LineMetrics can be obtained directly from the Font, the text concerned, and the FontRenderContext, which is based on the AffineTransform (if any), and whether the rendering is anti-aliased or uses fractional metrics. The text concerned can be a String or a CharacterIterator, providing access to character attributes. Also available directly from Font are java.awt.font.GlyphVectors and the layoutGlyphVector method, which does bi-directional layout.

In addition, in java.awt.font are TextAttribute, TextLayout, LineBreakMeasurer, TextMeasurer and GlyphMetrics. LineMeasurer is of limited utility, because it only implements a default line break policy, but TextMeasurer allows much finer control. GlyphMetrics seems to be the preferred direction for layout measurement, giving precise dimensions for glyphs in a particular piece of text, laid out in a particular FontRenderContext.

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.

I agree.

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.

Given a logical layout, the final result is determined by the renderer's notion of glyphs, their metrics and their relationships. Is this not so?

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.

Although I have not considered the problems of embedding, I agree with your assessment here.

Peter B. West <>

Reply via email to