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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
