Re: fail on osx between 2/4/2009 and 2/5/2009

[Kenichi Handa]

In article <address@hidden>, Adrian Robert <address@hidden> writes:

> On Feb 14, 2009, at 3:03 PM, Kenichi Handa wrote:
> >
> > :script -- script name symbol.  script-representative-chars
> > can be used as an additional hint to find a font.
> >
> > :lang -- symbol of iso639 two-letter language code.
> >
> > :otf -- see the docstring of query-font
> >
> > and I'm going to add:
> >
> > :chars -- the same format as the cdr part of each element of
> > script-representative-chars.

> OK, thanks, I'll work on responding to them in the NS backend (though  
> I'm unsure about the OTF stuff).  Does this new mechanism of   
> displaying chars in any script (through passing :script to the  
> backend when asking for fonts) operate with any fontset (e.g., if the  
> user does set-frame-font or similar), or is it only when the user is  
> using the so-called "default" fontset?

A font-backend doesn't have to case about fontset.  In other
words, :script property may appean in a font-spec stored in
any fontsets.

> As far as prioritization, it was said earlier that :chars should  
> override anything in script-representative-chars.  What about  
> priority between :lang and :script?  From the backend impl's  
> perspective, does :lang really need to be worried about if :script is  
> present?

In `list' method, all properties in a font-spec must be
sutisfied. If both :script and :lang are specified, it must
return fonts that satify both property.  On the other hand,
`match' method can return a font that, a font-backend
thinks, most fit with the specs.  So, it can put any
priority to the properties, and can even ignore some of
them.

> Will there be times when match() or list() receives a spec  
> with :lang only (and no :script)?

Yes.

> Also, is there a plan to update the documentation for match() and list 
> () in font.h?  I'm willing to do this (after I've finished and tested  
> my new implementation) if no one else has time.

I don't know what else should be added to the
documentations, but if you think the current ones must be
improved, please go ahead.

---
Kenichi Handa
address@hidden