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

[pipcet@protonmail.com]

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

> pipcet@protonmail.com writes:
>
>> 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?
>
> Right, I misunderstood FreeType's implementation.  Also fixed.

Thanks again! I really appreciate that there's a second set of eyeballs
going over these before pushing to master, let alone emacs-30 :-)

The next issue on my LineageOS (an Android variant) phone is that the
Noto CJK fonts have an "OTTO" header, not a "true"/00010000 one, so
they're not enumerated at all. At first glance, this doesn't appear to
be a LineageOS quirk; downloads available elsewhere also have the OTTO
header.

My understanding of the source code is we currently don't support OTTO
fonts at all, and my experiment in forcing the header to be recognized
seems to agree with me there: I get tofu even for ASCII characters,
which FontForge indicates are present in the font.

I have (lossily!) converted Noto Sans CJK SC to TTF format (with a
"glyf" table), and installed that in
/data/data/org.gnu.emacs/files/fonts, customized the "region" face to
use that font, and now I can see some Han characters when I select them,
but they turn into tofu when using the default face. (It's possible this
is due to the experiment I've described above and goes away when I
revert it...)

Of course, Noto CJK doesn't provide U+20000 (it does provide U+2000B),
so all this is a bit off-topic.

Pip