...Peter B. West wrote:
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.
This is only opposite in the sense of how the abstraction works. Your approach is pretty sound, and, assuming that you can solve the embedding problem, has some merit. However, there is no reason that the isolated Font logic can't use the awt objects that you are interested in to do the work behind the interface that FOray is building (or something similar). By isolating all of this code, you can have your cake and eat it too. You can use awt if, when, and how much it really makes sense, and you can do all kinds of other stuff as well for places where awt is inadequate. For example, awt gives access to the OpenType tables, but really doesn't do anything with them. FOray wants to use that information, and I assume that FOP will eventually want to also. So, why limit yourself to awt? As I said before, even if awt were perfect, there is still value in hiding it, especially during a refactoring stage.
I am interested in the 2D approach for a couple of reasons. Firstly, because I want a testbed for alt-design layout sooner rather than later. Secondly, I was looking for a approach to fonts and layout that was not PDF-centric and that might be familiar to new folks coming in, so the idea of modelling it on 2D appealed. Clearly, there is nothing of overwhelming relevance to HEAD in either approach.
...
Yes, and the renderer gets that information from the Font, which is still the same Font, and has no idea who is using it or why or how.
I don't deny that the concept I have described as RenderContext (you may have been off-line when we discussed this about a year ago) may affect layout. Those differences must be considered during layout (but the logic of handling them should not be done by the layout classes). RenderContext describes the capabilities that are available, presumably what fonts are available in this context, but could also include other things (can't kern, can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and PostScript use the same RenderContext, but if there are differences, then they can each have their own. Once these capabilities are defined, they must be considered as the FOTree is built, and as layout is performed.
So, while the Font is always a constant, it needs to be "filtered" through the lens of the RenderContext before it can be used properly. That is probably why the Font stuff ended up in the Render classes. And that is (part of) why I think, as FOP grows up here, it is important to distinguish between the Renderer and the RenderContext.
java.awt.font.FontRenderContext performs this function for 2D font rendering. The arguments to the constructor are the AffineTransform for scaling typographical points to renderer pixels, and the booleans isAntiAliased and usesFractionalMetrics.
If you'll give me a few weeks, I hope to be able to show you what I seem unable to sell with words.
It will be good to see what you come up with.
Peter -- Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
