Re: master bf0aeaa0d7a: Re-enable displaying `han' characters on Android

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Aug 2024 08:07:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I've reverted the above commit.  The change which added those
> > characters was not an accident: I found that Emacs would choose an
> > inappropriate (sub-optimal) font for Chinese characters because it
> > generally stops looking once it find the first font that fulfills the
> > requirements.
> 
> The reason behind your discovery is that with your choice of
> `script-representative-chars', no font will ever match this font spec
> (in the default fontset):
> 
>           ,(font-spec :registry "iso10646-1" :script 'han)
> 
> so that Emacs returns to the preceding ones, which specify a design
> language rather than a script:
> 
> 	  ,(font-spec :registry "iso10646-1" :lang 'ja)
> 	  ,(font-spec :registry "iso10646-1" :lang 'zh)
> 
> which is supported elsewhere than on Android.

I don't understand what you are saying.  What is "my discovery"?  And
why no font will ever match the font spec for 'han'? I've definitely
seen fonts that support _all_ of the characters I added to
script-representative-chars, so why wouldn't they be found?

> > The font Emacs sometimes selects due to those characters missing
> > lacked support for important Han blocks because those blocks had no
> > characters in script-representative-chars.
> 
> I didn't revert your change in whole, only characters beyond the BMP
> that seldom appear in real Chinese writing; of the characters that were
> deleted:
> 
>   #x1f210 #x20000 #x2a700 #x2b740 #x2b820 #x2ceb0 #x2f804

I added them because when those sub-optimal fonts are selected, some
of these characters appear as "tofu", which is ridiculous on a system
that has fonts installed that cover all of them.

And "seldom" is in the eyes of the beholder, at least IME.  When one
has text with these characters, the absolute frequency of their
appearance is not very relevant; what _is_ relevant is the fact that
the character cannot be shown by Emacs.

> the first is "SQUARED CJK UNIFIED IDEOGRAPH-624B", which is a stylized
> variant of its base character that is absent from Droid Sans Fallback.
> The remainder, #x2a700, #x2b740, #x2b820, #x2ceb0, and #x2f804 are
> esoteric characters that are provided by no CJK font on my GNU/Linux
> system, or compatibility ideographs that were never designed to be
> displayed.  Needless to say, neither are they provided by any of the CJK
> fonts users will probably install on Android

If there's no fonts installed that support those representative
characters, and Emacs is capable of finding less capable fonts that
support some of CJK (e.g., the BMP blocks), then why is that a
problem?  The purpose of the change is to allow Emacs to find better
fonts if they are installed, instead of ignoring them.  How is that a
Bad Thing?

I still don't understand why this breaks Android, btw.  If Emacs
employs the fallback font specs with :lang you show above, why don't
they work for Android?

> > If this causes problems to Android, then please implement a fix that
> > is specific to Android, without affecting other platforms.
> 
> It does affect other platforms, but I'm only in the habit of installing
> master regularly on Android.

The log message talked only about Android.  If users on GNU/Linux
report problems caused by this change, with enough details to
understand the problems, we can reconsider the change and modify it or
even revert.  But I do need the details on those other platforms to
think and discuss this intelligently.  This is all about details, it
isn't an abstract or academic issue.  Choosing which characters to
consider representative is frequently a judgment call based on
practical considerations and practical problems with existing fonts.