RE: font state and associates

[Victor Mote <vi...@outfitr.com>]

Keiron Liddle wrote (a long time ago, July 18 to be exact):

> Has anyone looked at the font state stuff.
> It appears we could make some changes to improve the way fonts are
> handled.
>
> - handle font information easily
> - handle font lists, resolving on a char basis
> - reduce number of FontState objects if information is the same (or
> similar?)
> - allow for serialization as part of area tree
>
> Do we need the FontInfo and FontMetric inside the FontState?
> Can we have a list of all font states so that it can be retrieved when
> needed for a particular layout of area?

My refactoring work will eventually handle most of this. However, I do not
understand item 2: "handle font lists, resolving on a char basis". There are
some lists in the FontInfo class now, which will end up as static fields in
the new Typeface class (with Typeface instances behind them), and I will
clean them up in the stage 2 work. The part I don't understand is the
"resolving on a char basis". What does this mean? Thanks.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: font state and associates

[Keiron Liddle <ke...@aftexsw.com>]

On Wed, 2002-10-23 at 21:41, Victor Mote wrote:
> Keiron Liddle wrote (a long time ago, July 18 to be exact):
> 
> > Has anyone looked at the font state stuff.
> > It appears we could make some changes to improve the way fonts are
> > handled.
> >
> > - handle font information easily
> > - handle font lists, resolving on a char basis
> > - reduce number of FontState objects if information is the same (or
> > similar?)
> > - allow for serialization as part of area tree
> >
> > Do we need the FontInfo and FontMetric inside the FontState?
> > Can we have a list of all font states so that it can be retrieved when
> > needed for a particular layout of area?
> 
> My refactoring work will eventually handle most of this. However, I do not
> understand item 2: "handle font lists, resolving on a char basis". There are
> some lists in the FontInfo class now, which will end up as static fields in
> the new Typeface class (with Typeface instances behind them), and I will
> clean them up in the stage 2 work. The part I don't understand is the
> "resolving on a char basis". What does this mean? Thanks.

Those fonts in the font info class are the fonts available to the system
from default + embedded fonts.
I was refering to a list of fonts in the font-family attribute in the fo
document.
If I remember correctly it should keep the list of family names and
lookup the character depending on the font-selection-strategy. If it is
charactar-by-character then it will need to know if the font has that
character in its range otherwise to try the next font family in the
list. It needs to do this twice, for getting the char width and for
resolving the mapping.
This is only a rare case but it should be considered in the design.

The serialization part in trunk is handled by using the string internal
font name as a key.




---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org