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
