Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 553a9a78402334c54130e294c5d5638b8bfb3971
https://github.com/WebKit/WebKit/commit/553a9a78402334c54130e294c5d5638b8bfb3971
Author: Ahmad Saleem <[email protected]>
Date: 2026-08-14 (Fri, 14 Aug 2026)
Changed paths:
A
LayoutTests/fast/text/shaping-across-inline-boxes-with-font-change-expected.html
A LayoutTests/fast/text/shaping-across-inline-boxes-with-font-change.html
A
LayoutTests/fast/text/shaping-across-inline-boxes-with-trailing-simple-text-expected.html
A
LayoutTests/fast/text/shaping-across-inline-boxes-with-trailing-simple-text.html
M Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp
Log Message:
-----------
[text shaping] Arabic letters in adjacent inline boxes are not joined when
the content is followed by simple code path text
https://bugs.webkit.org/show_bug.cgi?id=321259
rdar://184071471
Reviewed by Alan Baradlay.
LineBuilder::collectShapeRanges walks the candidate content and collects the
ranges of
shapable content that span inline box boundaries. When it ran into content that
cannot be
part of the current range -either because the content is not eligible for
shaping (simple
code path, combined text or non-RTL) or because it uses a different font- it
discarded the
entire candidate range instead of closing it.
A single trailing full stop was therefore enough to lose shaping for the whole
word e.g.
<div dir=rtl
lang=ar><span>ٱ</span>...<span>ة</span><span>.</span></div>
Here the '.' text box takes the simple code path, so the accumulated range for
the Arabic
content in front of it got dropped and each character ended up being shaped on
its own and
rendered in isolated form (which also made the content measure wider than the
equivalent
plain text).
Content that is not eligible for shaping should only terminate the shaping
range. Let's
commit what we have collected so far instead of throwing it away and, when the
terminating
content is itself eligible for shaping (i.e. this is the font change case),
start a new
range at it (and remember its font as the one to match against).
Both tests are reference tests so that the letter forms are checked and not
just the
resolved width. The reference has the same inline box structure as the test,
except that
the content which has to end up in one shaping range is put in a single inline
box (where
shaping across inline boxes is not needed at all). The font change test uses
the same font
file under two family names so that the two halves of the content have
mismatching font
cascades while still rendering identically.
* Source/WebCore/layout/formattingContexts/inline/InlineLineBuilder.cpp:
(WebCore::Layout::LineBuilder::collectShapeRanges const):
*
LayoutTests/fast/text/shaping-across-inline-boxes-with-font-change-expected.html:
Added.
* LayoutTests/fast/text/shaping-across-inline-boxes-with-font-change.html:
Added.
*
LayoutTests/fast/text/shaping-across-inline-boxes-with-trailing-simple-text-expected.html:
Added.
*
LayoutTests/fast/text/shaping-across-inline-boxes-with-trailing-simple-text.html:
Added.
Canonical link: https://commits.webkit.org/319209@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
