[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: |
Kenichi Handa |
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@gnu.org>, Jason Rumney <jasonr@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@m17n.org
- 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, 2009/06/18
- 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, 2009/06/22
- 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),
Kenichi Handa <=
- 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, 2009/06/22
- 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), Kenichi Handa, 2009/06/22
- 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, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Jason Rumney, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Dan Nicolaescu, 2009/06/22
- bug#3650: M-x gdb unusable on Windows, Nick Roberts, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Kenichi Handa, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Nick Roberts, 2009/06/23
- bug#3650: M-x gdb unusable on Windows, Jason Rumney, 2009/06/23