Description
This is an elaboration of the kind of issue I describe in #8:
Browsers’ text engines have a close interrelationship between font fallback, bidi processing, line breaking, and shaping, which cannot be matched using this API proposal.
Here's an example. Consider this string:
He said "אבא שלי ואני קנינו iPhone אתמול" while skiing.
This string has LTR inside RTL inside LTR.
On a single line, it would be rendered like this:
The reading order is this ("1" means "read this first" and "5" means "read this last"):
He said "אבא שלי ואני קנינו iPhone אתמול" while skiing.
[ 1 ] [ 4 ] [ 3 ] [------ 2 ------] [---- 5 ----]
Now, let's imagine we're laying this string out in some available width. Let's say that the first five words fit on the first line, the next 3 words fit on the next line, and the remaining 2 words fit on the last line.
It should be rendered like this:
Here's the reading order:
He said "אבא שלי ואני
[ 1 ] [--- 2 ----]
אתמול iPhone קנינו"
[ 5 ] [ 4 ] [ 3 ]
while skiing.
[---- 6 ----]
However, if you naively chop up the string into lines and render each line independently, you'd get this incorrect rendering:
(Notice the middle line in particular.)
This is because, if you render each line independently, that middle line loses the context from the first line. From the text engine's perspective, the middle line would look like 3 separate sibling phrases, rather than one big RTL phrase with a single LTR word inside it.
In order to solve this problem, the line layout code needs to have knowledge of the bidi state around each line, which Intl.Segmenter v2 does not include.