GNU bug report logs - #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)

Previous Next

Full log

View this message in rfc822 format

From: Kenichi Handa <handa <at> m17n.org>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 3208 <at> debbugs.gnu.org, schierlm <at> gmx.de
Subject: 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)
Date: Mon, 22 Jun 2009 20:22:38 +0900

In article <4A3F1B05.7030105 <at> gnu.org>, Jason Rumney <jasonr <at> gnu.org> writes:

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

That will lead to slow display, but I don't understand why
that leads to memory full problem.  How many fonts do people
have on Windows roughly?  On GNU/Linux, I have about 700
fontconfig fonts and 4500 X fonts.

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

??? JISX0208 surely contains U+2203 (THERE EXISTS).

By the way, in short, which part of the current code is
wrong?  Do you mean that there's a bug, or that the current
strategy doesn't work for Windows?

---
Kenichi Handa
handa <at> m17n.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.