Jeremias Maerki wrote:

> TextInfo looks better but could IMO be merged with FontState which only
> hold the font name and size and a link to the FontMetrics. Anyway, I
> think this merged class will be a candidate for the Flyweight pattern so
> we don't generate so many TextInfo/FontState objects (one for each FObj
> I think). Brings up the question of efficiently looking up existing
> Flyweights, on the other side.

I also saw elements of the Facade pattern here on the font stuff. I
documented some of these thoughts at I suppose a wiki would have been
better & that is pretty much how I viewed this page -- the point is to feel
free to hack away at that document if you wish. It looks like you have
started some of the moving and consolidating work that needed to be done
with the scattered classes. I thought that most of the surviving
font-related classes should be private & used only by a Font class that was
a Facade for all of the underlying types of fonts, including (eventually)
AWT fonts seen by any existing graphical environment. I was all set to put
the FontInfo into static variables so that it didn't have to be passed
around so much. I see that multiple threads make that a bad idea. What we
need (and probably already have -- I haven't had time to look) is the
equivalent of a Document class that the FontInfo lists can be put into.
Thus, our Font, Typeface, and TypefaceFamily classes apply to an FOP
Session, but the  /Document/ object keeps a list of at least Typeface
information for purposes of embedding & listing at render time. The
/Document/ object needs to get passed almost everywhere, but at least all

I think the FontMetrics should eventually be seen only by the Font object.
However, it might need to be a Facade itself to deal with the different ways
font metric information can be returned.

To get the Flyweight working, when a Font resource is requested during
layout, we have to look in the tables of pre-existing objects (this should
be static), and either return an existing one or create a new one, then also
update the /Document/ info.

Something like FontState or TextState (one or the other) is probably good to
keep pointers to all of this stuff (including Font) in one place. However,
since the other items are basically (I think) boolean in nature (underline
on or off), maybe it is just as good to simply pass the area object around
which should have all of this stuff. One of the "bad smells" was the amount
of information that had to be passed to get anything done.

I don't know how this matches up with where you are going, but I thought I
ought to throw it out there FWIW. You are probably way ahead of me on all of
this. Also, I thought that a discussion of how "Session" stuff is separated
from "Document" stuff for multithreading might be worthwhile.

It will probably be a couple of weeks before I can get back into this much.
Sorry to be on the sidelines for a bit.

Victor Mote

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to