[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Display of decomposed characters
From: |
Philipp |
Subject: |
Re: Display of decomposed characters |
Date: |
Sun, 21 Mar 2021 12:43:47 +0100 |
> Am 19.03.2021 um 17:44 schrieb Eli Zaretskii <eliz@gnu.org>:
>
>> From: Philipp <p.stephani2@gmail.com>
>> Date: Fri, 19 Mar 2021 17:37:31 +0100
>> Cc: help-gnu-emacs@gnu.org
>>
>>>>>> What if Emacs ignored font lookup for combining characters and always
>>>>>> picked the font of the previous base character?
>>>>>
>>>>> What would that produce if the font of the previous character didn't
>>>>> have a glyph for the accent? The accent will disappear, or maybe will
>>>>> be displayed as "tofu", right? Does that sound like a good strategy?
>>>>
>>>> Can't the shaping engine produce fake compositions in that case?
>>>
>>> What do you mean by "fake compositions"? what would they entail, and
>>> which glyphs would they use?
>>
>> For example, the shaping engine could use U+00A8 (assuming it's available in
>> the font), but place it on top of the base glyph, without horizontal shift.
>
> First, we were talking about the case where U+00A8 is NOT available in
> the font. (If it _is_ available, then this whole discussion is
> pointless, because things already work well in that case.)
No, the case is that U+00A8 (the spacing diaeresis) is available, but U+0308
(the combining diaeresis) is not.
>
>> (At least that would be a possibility; I don't know whether Harfbuzz
>> actually does that.)
>> That would still produce suboptimal results, but probably slightly better
>> ones.
>
> I don't understand what you are describing here. If the font does
> have U+00A8, what you describe already happens. If the font doesn't
> have the glyph, what can the shaper do?
See above, here I'm assuming that U+0308 is unavailable not U+0048.
>
> The horizontal shift happens because we use U+00A8 from a different
> font. Placing a glyph from a different font on top of a base glyph is
> in general an impossible task, because different fonts have different
> ways of describing the points where the accents shall be placed on top
> of base characters.
Yes, but a fallback option where the two glyphs would just be centered
horizontally on top of each other would be at least thinkable. It wouldn't
give great results, but I wouldn't call it impossible.
>
>> The optimal approach (for this case) would still be to try out composition
>> before font selection, and use that if it works.
>
> I tried to explain why that's not possible, but I guess I failed
> miserably.
At least I'm not convinced. Surely it's possible to call
ucs-normalize-NFC-string before selecting fonts or sending a combined character
sequence to the shaping engine, it produces optimal results in this case (I've
tried it), and
https://lists.freedesktop.org/archives/harfbuzz/2011-July/001426.html appears
to talk about something very similar. The question is rather whether this
normalization would cause more problems than it fixes; at least the Harfbuzz
approach shouldn't.
>
>> I should note that Emacs is not alone in producing suboptimal results in
>> this case; other GUI programs on that systems appear to either perform the
>> fake composition I mentioned before, or no composition at all (placing the
>> base and combining characters next to each other).
>
> Which should tell us something about the issue and the ways it can and
> cannot be solved.
>
It tells us that it's a difficult problem, as text rendering is in general.
But it's not unsolvable: for example, I just tried Firefox and Google Chrome,
and both produce optimal results.