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

[pipcet]

"Po Lu" <luangruo@yahoo.com> writes:

> 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.

Thank you!

One more thing I'm noticing is that on Android, the foundry
string/ach_vendor_id is interned as OG^A@ rather than GOOG. It seems to
me that removing the second read() call in
daefd6771a4879bb8e71ea67f69522700155df01 may have caused the
problem. IIUC, panose[] is four-byte-aligned, but ul_unicode_range is
not, and that messes up our offsets. Is that correct?

Are we actually using ul_unicode_range, by the way?

>> 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.

You're right; I still wonder whether this is the intended behavior...

Pip