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

[Kenichi Handa]

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

> I meant my question more from a user perspective.  If they call 'set- 
> frame-font or similar, do ALL of the fonts, on, e.g., the HELLO  
> screen, get switched to be the most similar to the user's selection  
> with the appropriate charset, or does it just change the ASCII font?   

Yes, at least that is the intention.

> Experimenting with the non-freetype X build here, just set-frame-font  
> doesn't seem to do it, but selecting something from the shift-left- 
> mouse menu does (but I can't fully trace out what is getting called  
> in this case).

Then, it seems that there's a bug somewhere.  I'll work on it.

>>> 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.

> The full list of properties that can appear bundled under the  
> FONT_EXTRA property that are important for drivers to take into  
> account in match() and list() should be specified somewhere in font.h.

Ah, I see what you mean.

> In font.c there is font_property_table, which lists everything that  
> is a "first class" property in font.h (explicitly listed in  
> font_property_index), plus the following: 'lang', 'script', and  
> 'otf'.  While the font-spec function mentions 'script' and 'name',  
> but not 'lang' or 'otf'.  I'm not sure about the criterion for  
> putting something under "EXTRA" or listing it in one place or another  
> in font.c, but if the font driver should respond to it, especially  
> for something as important as core emacs font selection, it should be  
> mentioned in font.h.

Ok, I'll document them.

---
Kenichi Handa
address@hidden