On Thursday 26 July 2007 00:23, Andreas L Delmelle wrote: > On Jul 25, 2007, at 02:25, Manuel Mall wrote: > > On Wednesday 25 July 2007 05:17, Andreas L Delmelle wrote: > >> Anyone have any objections, for instance, to change the default > >> behaviour of FontInfo.fontLookup(String[], ...) to something like > >> the below code? Should we add a getFontInstances() method too, or > >> rather, since the below method is only used by CommonFont, maybe > >> merge it into such a getFontInstances() method, that would return > >> Font[]? > >> > >> To Manuel in particular: what would be most convenient from your > >> point of view? Is it OK if each LM gets a set of Fonts (or mere > >> triplet-keys), instead of only one, upon the call to > >> getFontState()? > > > > LMs tend to call these methods only once typically in their > > initialize method. A quick search shows that getCommonFont() is > > called only 8 times in the LMs and in each case the call is the > > same: > > > > font = > > <fobj>.getCommonFont().getFontState(<fobj>.getFOEventHandler > > ().getFontInfo(), > > this); > > > > In summary LMs are not really interested in the CommonFont object > > as such. They only use it to get to the Font object (or now we want > > a list > > of Font objects) applicable to them. But the LMs would like a Font > > object not a Triplet. > > OK, just wondering because the FontInfo instance that CommonFont uses > to do the lookup ultimately gets passed in by the LM. Maybe in some > cases it could be a more efficient use of resources to have > CommonFont.getFontState() return only the compact triplet-objects in > an array, which the LM can then later feed to the getFontInstance() > method of the FontInfo it has access to. If I remember correctly from > studying the fonts package, getFontInstance() would also actually > *load* the font if that is not yet done at the point the method is > called. If a user were to specify 20 font-families, they would all be > loaded even when only one of them is actually used. Can't remember > exactly if Adrian's auto-detection patch changed this in any way. > > > So, IMO the least impact change is to simply add font[] > > getFontStates(...) to CommonFont. How it is implemented internally > > doesn't really worry me. > > We can even make it a bit more flexible, I think. > Make it FontTriplet[] as a return type, and add the getFontInstances > (FontTriplet[],...) method to FontInfo. > > That way, the LM can ask all Font instances at once (if it wants/ > needs to), or just the first one to initialize from and create the > others only if necessary. > > IOW, the code in the LM could come to look like: > > //init() > fontkeys = <fobj>.getCommonFont().getFontState > (<fobj>.getFOEventHandler().getFontInfo()); > > //instantiate the fonts, one ... > initfont = <fobj>.getFOEventHandler().getFontInfo.getFontInstance > (fontkeys[0], this); > ... > > //other_method() > //... by one > fallbackfont = <fobj>.getFOEventHandler().getFontInfo > ().getFontInstance(fontkeys[x], this); > //or if desired, create them all at once > //preferably not used for large sets of unloaded fonts (?) > allfonts = <fobj>.getFOEventHandler().getFontInfo().getFontInstances > (fontkeys, this); > > > > WDYT?
Yes, that will work I think. Thanks Manuel > Thanks for the feedback. > > Cheers > > Andreas
