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

Reply via email to