bug#19993: 25.0.50; Unicode fonts defective on Windows

[Ilya Zakharevich <ilya@math.berkeley.edu>]

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