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

Reply via email to