bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32)

[Jason Rumney <jasonr@gnu.org>]

Kenichi Handa wrote:
> Could you please find why font_find_for_lface is called so
> releatedly by setting breakpoint in fontset_find_font (with
> condition "c == 0x2203)?
>   

What appears to be happening, is that font_find_for_lface is returning 
many fonts that match the requested spec, but do not contain the 
character required. Because has_char is effectively not implemented in 
the w32 backends, this isn't detected until late, and the negative 
result is either not cached, or is cached according to the original font 
spec which many unusable fonts match.  On subsequent calls, all the 
checking to see which fonts really contain the character required is 
repeated.


On first call to fontset_find_font:

    fontset_get_font_group returns nil (no spec in fontset)

Second call (with default fontset):

    fontset_get_font_group returns a single spec matching registry 
"iso10646-1", script "symbol"
    font_find_for_lface returns the font "Lucida Console", which does 
not contain the desired character.

Third call (with fallback):

    font_find_for_lface returns "Courier New", with registry "iso8859-1" 
then nil

Forth call (with fallback):

    font_find_for_lface returns nil

....
    eventually font_find_for_lface returns "MS Mincho" with registry 
"jisx0208", which does contain the corresponding character (albiet 
double width, looking suspiciously like katakana YO and not encodable by 
jisx0208). There may be an incompatibility in the w32 font handling 
here, because all truetype fonts are effectively unicode fonts, but we 
return them when other registries that the font can manage are 
requested. This is because Emacs requests iso8859-1 and other 8-bit 
registries before requesting iso10646-1, and if we only return bitmap 
fonts for those we will end up with an ugly display by default.