[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#3208: 23.0.93; Memory full / crash when displaying lots of character

From: Jason Rumney
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 13:47:49 +0800
User-agent: Thunderbird (Windows/20090302)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]