bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#19993: 25.0.50; Unicode fonts defective on Windows


From: Eli Zaretskii
Subject: bug#19993: 25.0.50; Unicode fonts defective on Windows
Date: Wed, 04 Mar 2015 19:59:56 +0200

> Date: Tue, 3 Mar 2015 14:02:28 -0800
> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> 
> (A) On Windows, most Unicode characters won’t be shown, even if the system 
>     has (many) fonts covering the characters (and these fonts are listed in 
>     `font-log'!).

Examples, please: they are required to debug the issue.  Please
include with the examples the information about the font(s) which
support the problematic characters, but are not used although
installed.  Or, if you already debugged this and can tell which code
misbehaves, please post that information.

> (C) Even if a character is (eventually) shown, it may take several seconds
>     after the character is typed.  E.g., typing
>
>     gives a 2sec delay on my system (a pretty quick PC).  It is shown using
>       uniscribe:-outline-MS 
> Gothic-normal-normal-normal-mono-13-*-*-*-c-*-jisx0208*-* (#x3D3)

That delay should happen only once, when any character from the font
is first displayed.  The next character from the same font should not
cause any perceptible delays.  If this is what you see, then the delay
is due to the font driver (a.k.a. "shaping engine", Uniscribe on
Windows) searching the system for a suitable font, under control of
the Emacs code (in font.c and fontset.c).

A good example of this is "C-h H": the first time you type that in
"emacs -Q", it takes a long time before the HELLO buffer displays.
But if you kill that buffer and immediately invoke "C-h H" again, the
display is instantaneous.

This is not specific to Windows in any way, AFAIK, the Emacs code
which looks for a suitable font is system-independent.

If there are ways to speed up font search, we should do that, of
course.  Patches to make the search speedier are welcome.

> (D) After typing as in (C), many operations become unusable.  (E.g., showing 
>     documentation for font-log takes several minutes to display the end of 
>     the buffer.  Save the buffer to a file — and it takes 4.5MB.)

Yes, similar to "C-h H".  Any buffer that uses a lot of different
fonts will hit this.

>   2) one should make the list of encodings to load (I mean those in 
>      `describe-fontset') system-dependent, and — on contemporary 
>      systems — default to iso10646 *ONLY*.

Sorry, I don't understand what that means.  First, why should the list
of encodings be system-dependent?  Those encodings are universal,
i.e. there are no encodings that are unusable on any particular
system.  And your suggestion to use iso10646 actually means it will be
system-independent, no?

Second, what do you mean by "default to iso10646"?  Do you mean that
by default there should be no support for other encodings?  If so,
why?

Or maybe you mean that the default font used by "emacs -Q" should
support as wide a range of Unicode as possible?  If so, I think we
already do that.

>   3) Improve the docs (but I would try to address this in a separate
>      bug report).

Indeed, font-related issues in Emacs are notoriously under-documented,
both on the user level, and on the ELisp level.





reply via email to

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