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

[Po Lu <luangruo@yahoo.com>]

pipcet@protonmail.com writes:

> "Benjamin Riefenstahl" <b.riefenstahl@turtle-trading.net> writes:
>
>> Benjamin Riefenstahl writes:
>>> I don't know what is going on.  Must have been something I did earlier
>>> in that other session.
>>
>> It's the order.  If I first evaluate the version with fewer characters,
>> I get a font for that and for the longer list of characters after that,
>> too.
>
> I've looked at that a little, and I don't think 'clear-font-cache', uh,
> clears the font cache.
>
> ftfont.c also interns random binary strings as symbols here. This helps:
>
> diff --git a/src/ftfont.c b/src/ftfont.c
> index c89feea1d46..882d3eec256 100644
> --- a/src/ftfont.c
> +++ b/src/ftfont.c
> @@ -174,11 +174,11 @@ get_adstyle_property (FcPattern *p)
>    USE_SAFE_ALLOCA;
>    tmp = SAFE_ALLOCA (end - str);
>    for (i = 0; i < end - str; ++i)
> -    tmp[i] = ((end[i] != '?'
> -	       && end[i] != '*'
> -	       && end[i] != '"'
> -	       && end[i] != '-')
> -	      ? end[i] : ' ');
> +    tmp[i] = ((str[i] != '?'
> +	       && str[i] != '*'
> +	       && str[i] != '"'
> +	       && str[i] != '-')
> +	      ? str[i] : ' ');
>    adstyle = font_intern_prop (tmp, end - str, 1);
>    SAFE_FREE ();
>    if (font_style_to_value (FONT_WIDTH_INDEX, adstyle, 0) >= 0)

[...]

> sfntfont.c only looks at the first fixnum in a vector specified in
> Vscript_representative_chars, and fails if it isn't there, even though
> it should continue looking.

These have been fixed.

> xfont.c is particularly weird: it's limited to 64k characters, of
> course, but it also hardcodes 'han as a supported script for all
> Japanese or Korean fonts; and xfont_has_char will return false for all
> non-ASCII chars in iso10646-1 fonts that don't have "ja" or "ko"
> adstyles. In addition, it has its own caching mechanism
> (xfont_scripts_cache) which is never cleared, shrunk, or exposed to
> Lisp.

No, xfont_has_char will return a value that indicates that the presence
of the character cannot be established without opening the font.

> w32font.c seems to ignore Vscript_representative_chars entirely. This
> also appears to apply to the harfbuzz backend.

I wouldn't tamper with either of these backends.

> GNU Unifont now supports #x20000 (since February), but is split into two
> fonts, one for the BMP and one for the upper planes, so it won't be
> detected here.
>
> So I'm not sure which font backends the additional required characters
> are supposed to have a positive effect on.

All except w32font, I guess.