Peter B. West wrote: > > 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.
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. > > 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? 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. If you'll give me a few weeks, I hope to be able to show you what I seem unable to sell with words. Victor Mote
