bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly


From: Benjamin Riefenstahl
Subject: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly
Date: Tue, 01 Jan 2019 22:40:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii writes:
> I asked whether the problem happens with other fonts, not with other
> characters.  Because you specifically mentioned the font.

Ah, I got confused with you mentioning Arabic.

Actually Noto is the only freely available font for Mandaic that I am
aware of.  I just mentioned it and its source to make it easier to
reproduce the problem.

As I said, other fonts seem to have similar problems with other
characters.  In the Syriac example, the same problem with the same
characters happens with other fonts.  OTOH all the fonts I have for
Syriac are made by the same company in a single package, so I expect
them all to contain the same shaping information.

>> >   If this is nil (the default), the direction of each paragraph is
>> >   determined by the first strong directional character of its text.
>> >   The values of ‘right-to-left’ and ‘left-to-right’ override that.
>> >   Any other value is treated as nil.
>> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >
>> > Did you set it to t on purpose?  If so, can you explain why?
>> 
>> No, that was a mistake.  OTOH it seems that "is treated as nil" is not
>> true, because "t" has the same effect as "right-to-left".
>
> It does?  How do you see that?  Does the paragraph direction change to
> R2L when you set bidi-paragraph-direction to t?

I got confused there, because I expected the scratch buffer to use the
default for b-p-d, when it actually has it explictly set to ltr.  That
explains what I see.  Setting b-p-d to "t" in scratch changes the
behaviour, because than it uses default detection.

>> > Can you run Emacs under a debugger and see what value of 'dir' do we
>> > come up with in this snippet from ftfont.c:
>> >
>> >   hb_direction_t dir = HB_DIRECTION_INVALID;
>> >   if (EQ (direction, QL2R))
>> >     dir = HB_DIRECTION_LTR;
>> >   else if (EQ (direction, QR2L))
>> >     dir = HB_DIRECTION_RTL;
>> >   /* If the caller didn't provide a meaningful DIRECTION, let HarfBuzz
>> >      guess it.  */
>> >   if (dir != HB_DIRECTION_INVALID)
>> >     hb_buffer_set_direction (hb_buffer, dir);
>> >
>> > Do we call hb_buffer_set_direction, and if so, with what value?
>> 
>> With "t" or right-to-left we have dir == HB_DIRECTION_LTR, and yes we go
>> into that function.  With the default (nil) or left-to-right we have dir
>> == HB_DIRECTION_RTL and we also call that function.
>
> When the value is nil, do you see the text that starts with Mandanaic
> or Syriac letters begin at the right margin of the window?  IOW, do
> you see that the paragraph direction changes when the paragraph begins
> with a strong Right to Left letter?  Or does the text still get laid
> out starting at the left margin of the window?

Yes.  With b-p-d set to rtl or nil I get the text at the right margin
but with the shaping error.  With the default value ltr the text is at
the left, and the shaping error is gone.  This is always with changing
the script and restarting Emacs.

When I add an "x" at the beginning in the script and set b-p-d to nil,
the text is at the left and with correct shaping.  If I set b-p-d to nil
and interactively add or remove an "x" at the beginning of the line, the
place where the text goes changes accordingly but the shaping does not
change, the form persists that the script initially causes.  I executed
clear-font-cache, but that does not make the shaping change in this
scenario either.

Can I test something else?

benny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]