Peter B. West wrote:

> > BTW fonts aren't the only considerations, others are color and the
> > discretization of coordinates (e.g. bitmap vs. vector format).
> All of which leads me to the question of what, exactly, we are trying to
> isolate and amalgamate in the font system.  We can't get away from
> renderer dependencies, so the target renderer is going to have to be
> accommodated before any atomic elements are introduced to the Area Tree.
>   As I said, I haven't been closely following the fonts discussion, but
> I'm confused as to where it fits in the scheme of things, and what it is
> trying to achieve.

I think what we are trying to do is to separate Font details from the Layout
and Render processes as much as possible. Renderer dependencies need to
drive font selection, but by the time the Layout or Render actually start to
do their work, those issues should already be resolved.

Your inquiries here have actually caused me to rethink Fonts a bit. My view
of FOP's overall design (I apologize for brining this up again, but it is
necessary to explain the point) is that we have a Session (Driver) which can
have multiple Documents, each of which can have multiple RenderContexts,
each of which can have multiple Renderers. (The RenderContext class exists
only in my mind right now, as I have failed to get support for it --
however, much of the discussion in this thread revolves around that
concept). Document controls the FOTree build, RenderContext controls the
Layout/Area Tree, and the Renderers simply render the Area Tree. Now, my
plan has been to have FOTree resolve to a Font object during parsing.
However, it is clear to me that actual Font resolution has to go with the
RenderContext concept. So, probably the FOTree needs to store more raw
information (perhaps in an FOFont object) that the RenderContext can resolve
into a Font during layout. The performance impact should be minimal, but I
think the extra layer of abstraction is important.

Victor Mote

Reply via email to