bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

[Thamer Mahmoud]

This also affects overlays and `transient-mark-mode' region.

1. Eval:

(with-current-buffer-window "*shaping testcase*" nil nil
  (insert "L2R عربي" "\n\n")
  (insert "عربي")
  (put-text-property 5 6 'face 'highlight)
  (put-text-property 11 12 'face 'highlight))

2. Notice the AIN(ع) in the L2R paragraph has the wrong shape.

--
Regards,
Thamer

bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

[Eli Zaretskii]

> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
> Date: Sat, 14 Nov 2020 15:42:35 +0300
> 
> (with-current-buffer-window "*shaping testcase*" nil nil
>   (insert "L2R عربي" "\n\n")
>   (insert "عربي")
>   (put-text-property 5 6 'face 'highlight)
>   (put-text-property 11 12 'face 'highlight))
> 
> 2. Notice the AIN(ع) in the L2R paragraph has the wrong shape.

This is a known limitation of the current Emacs display engine: it
cannot shape text across face changes.  All the text that needs to be
shaped must have the same face.  This problem has existed since Emacs
21.

Fixing this limitation would require a more or less complete redesign
of how the display engine scans the buffer text, or maybe some radical
changes in how character composition is handled.  Until one of these
changes, this problem will remain unsolved, sorry.

bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

[Thamer Mahmoud]

[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
>> Date: Sat, 14 Nov 2020 15:42:35 +0300
>>
>> (with-current-buffer-window "*shaping testcase*" nil nil
>>   (insert "L2R عربي" "\n\n")
>>   (insert "عربي")
>>   (put-text-property 5 6 'face 'highlight)
>>   (put-text-property 11 12 'face 'highlight))
>>
>> 2. Notice the AIN(ع) in the L2R paragraph has the wrong shape.
>
> This is a known limitation of the current Emacs display engine: it
> cannot shape text across face changes.  All the text that needs to be
> shaped must have the same face.  This problem has existed since Emacs
> 21.
>
> Fixing this limitation would require a more or less complete redesign
> of how the display engine scans the buffer text, or maybe some radical
> changes in how character composition is handled.  Until one of these
> changes, this problem will remain unsolved, sorry.

Shaping across face changes works for me in R2L paragraphs, but not in
L2R. See the attached screenshot.


[-- Attachment #2: shaping --]
[-- Type: image/png, Size: 9578 bytes --]

[-- Attachment #3: Type: text/plain, Size: 139 bytes --]



Wouldn't it be possible to extend the same behavior that is currently
working fine in R2L paragraphs to also apply to L2R ones?

Thanks.

bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

[Eli Zaretskii]

> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
> Cc: 44632@debbugs.gnu.org
> Date: Sun, 22 Nov 2020 19:58:03 +0300
> 
> Wouldn't it be possible to extend the same behavior that is currently
> working fine in R2L paragraphs to also apply to L2R ones?

Sorry, no.  Not without serious changes (basically, a redesign) in the
low-level code that iterates the buffer for rendering characters for
display.

bug#44632: 27.1.50; Left-to-right Arabic shaping breaks at property bounds

[Stefan Kangas]

tags 44632 + wontfix
close 44632
thanks

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
>> Date: Sat, 14 Nov 2020 15:42:35 +0300
>>
>> (with-current-buffer-window "*shaping testcase*" nil nil
>>   (insert "L2R عربي" "\n\n")
>>   (insert "عربي")
>>   (put-text-property 5 6 'face 'highlight)
>>   (put-text-property 11 12 'face 'highlight))
>>
>> 2. Notice the AIN(ع) in the L2R paragraph has the wrong shape.
>
> This is a known limitation of the current Emacs display engine: it
> cannot shape text across face changes.  All the text that needs to be
> shaped must have the same face.  This problem has existed since Emacs
> 21.
>
> Fixing this limitation would require a more or less complete redesign
> of how the display engine scans the buffer text, or maybe some radical
> changes in how character composition is handled.  Until one of these
> changes, this problem will remain unsolved, sorry.

Since this is a known limitation, I think it unfortunately doesn't make
sense to keep this bug open.  If anyone wants to work on a redesign of
the display engine, they will probably not do that due to this bug.

I guess it would be good if we could have a list somewhere of the known
limitations, so if anyone knows about something like that please add it.

But for now, I'm closing this as wontfix.