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: Eli Zaretskii
Subject: bug#33944: 27.0.50; harfbuzz: Noto Sans Mandaic not rendered correctly
Date: Tue, 01 Jan 2019 21:17:03 +0200

> From: Benjamin Riefenstahl <address@hidden>
> Cc: address@hidden
> Date: Tue, 01 Jan 2019 19:34:15 +0100
> 
> Eli Zaretskii writes:
> > You mean, with other fonts that support Arabic shaping the problem
> > doesn't happen?
> 
> Now that you asked, I get the same problem with some words in Syriac,
> like with this:
> 
>     (set-fontset-font t '(?\u0700 . ?\u07FF) "Serto Mardin 20")
>     (setq bidi-paragraph-direction 'right-to-left)
>     (insert "\u0718\u0726\u0720\u0713\u0717\u073F")
> 
> The characters should all be connected, but the third and fourth are not
> in this case.

I asked whether the problem happens with other fonts, not with other
characters.  Because you specifically mentioned the font.

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

> > What happens if bidi-paragraph-direction is set to one of the valid
> > values?
> 
> With right-to-left the same happens, with left-to-right it's good again
> (same as with the default).
> 
> >> The commit that breaks this is the last one, 48776b7011 "Provide text
> >> directionality and language to HarfBuzz shaper".  Before that commit it
> >> works for me.
> >
> > 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?

> Is this switched around somewhere?

Yes, this was the whole point of the changeset that succeeded in
breaking the shaping.  But I have an idea why this happens, and will
try to fix it.

Thanks.





reply via email to

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