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 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)
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 -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
