Package: emacs;
Reported by: Ilya Zakharevich <nospam-abuse <at> ilyaz.org>
Date: Tue, 3 Mar 2015 22:32:01 UTC
Severity: normal
Found in version 25.0.50
Message #11 received at 19993 <at> debbugs.gnu.org (full text, mbox):
From: Ilya Zakharevich <ilya <at> math.berkeley.edu> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 19993 <at> debbugs.gnu.org Subject: Re: bug#19993: 25.0.50; Unicode fonts defective on Windows Date: Thu, 5 Mar 2015 13:49:00 -0800
On Wed, Mar 04, 2015 at 07:59:56PM +0200, Eli Zaretskii wrote:
> > (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).
I have some doubts in this. I think you are theoretizing, while *I*
KNOW that what you expect from Emacs is NOT HAPPENING. (See below.)
> > (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.
I think the logical way is to choose one:
• either the font delay happens once, and this is not avoidable (as
you said above);
• or there is something fishy (since other applications do not need
minutes to show one screenful of information).
-------
Let us see the most important part of my report (the part you trimmed
away!):
…
¢ .. £ (#xA2 .. #xA3)
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-3
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-4
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-9
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-10
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-13
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-14
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-15
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-16
-*-*-*-*-*-*-*-*-*-*-*-*-viscii1.1-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
-*-*-*-*-*-*-*-*-*-*-*-*-jisx0208.1983-0
¤ (#xA4)
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-3
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-4
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-9
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-10
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-13
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-14
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-15
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-16
-*-*-*-*-*-*-*-*-*-*-*-*-viscii1.1-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
-*-*-*-*-*-*-*-*-*-*-*-*-gb2312.1980-0
-*-*-*-*-*-*-*-*-*-*-*-*-ksc5601.1987-0
¥ .. ¦ (#xA5 .. #xA6)
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-2
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-3
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-4
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-9
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-10
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-13
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-14
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-15
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-16
-*-*-*-*-*-*-*-*-*-*-*-*-viscii1.1-1
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
§ (#xA7)
…
As I said, these is 4500 lines of info — and ALL these lines are
excessive. On systems where the NATIVE font format is iso10646,
instead of all these lines, ONE LINE would be equivalent (at least
AFAIU — the stuff IS undocumented):
C-@ .. ø¿¿ (#x43 .. #x3FFFFF)
-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1
I do not see how such a change would not fix all the issues reported
here. (But I’m theoretizing! ;-)
> > 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?
In the best world, it should not: just use one encoding (iso10646),
and you are done (as above). And, as I said, this would probably work
in 95% of installations of Emacs. For the rest of (legacy) systems,
the current mess MIGHT be needed (theoretizing again!).
> 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?
Because on contemporary systems,
-X-Y-Z-T-U-V-S-R-K-L-M-N-iso8859-5
is just a subset of
-X-Y-Z-T-U-V-S-R-K-L-M-N-iso10646-1
(plus a lot of overhead added to do translations twice: first in one
direction, then in the opposite one!). Why look for glyphs in both?
=======================================================
BTW, I just noticed: `describe-fontset' produces a buffer starting as
Fontset: -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-fontset-startup
CHAR RANGE (CODE RANGE)
FONT NAME (REQUESTED and [OPENED])
C-@ .. x?=? (#x43 .. #x3FFF7F)
-*-*-*-*-*-*-*-*-*-*-*-*-iso8859-1
Where this #x43 cames from?!
Thanks,
Ilya
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.