WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
279008
text-emphasis only uses the first character in the grapheme cluster
https://bugs.webkit.org/show_bug.cgi?id=279008
Summary
text-emphasis only uses the first character in the grapheme cluster
yisibl
Reported
2024-09-02 00:00:03 PDT
Created
attachment 472401
[details]
text-emphasis-emoji Open the following code in Safari and you'll see that the text-emphasis is only rendered to `U+2764` data:text/html;charset=UTF-8,<!doctype html> <style> .foo { font-size: 52px; border: solid 1px blue; text-emphasis-style: "❤️"; display: inline; } </style> <div class="foo">test emoji❤️</div> ❤️ This emoji actually contains two characters: `U+2764` `U+FE0F`
Attachments
text-emphasis-emoji
(741.18 KB, image/png)
2024-09-02 00:00 PDT
,
yisibl
no flags
Details
test case
(198 bytes, text/html)
2024-09-02 12:38 PDT
,
Alexey Proskuryakov
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2024-09-02 02:08:03 PDT
<
rdar://problem/135133566
>
Alexey Proskuryakov
Comment 2
2024-09-02 12:37:55 PDT
This is not just emoji with variation selectors. Same issue with e.g. decomposed é, or regional indicators like 🇷🇺.
Alexey Proskuryakov
Comment 3
2024-09-02 12:38:29 PDT
Created
attachment 472406
[details]
test case Same test as attachment.
alan
Comment 4
2024-09-02 13:39:10 PDT
Looks like drawEmphasisMarks is broken. using drawBidiText instead makes the bug go away (note that this is not a fix proposal) diff --git a/Source/WebCore/rendering/TextPainter.cpp b/Source/WebCore/rendering/TextPainter.cpp index 8a84ad92b70b..4be4f964b5b9 100644 --- a/Source/WebCore/rendering/TextPainter.cpp +++ b/Source/WebCore/rendering/TextPainter.cpp @@ -117,7 +117,7 @@ void TextPainter::paintTextOrEmphasisMarks(const FontCascade& font, const TextRu } if (!emphasisMark.isEmpty()) - m_context.drawEmphasisMarks(font, textRun, emphasisMark, textOrigin + FloatSize(0, emphasisMarkOffset), startOffset, endOffset); + m_context.drawBidiText(font, TextRun { emphasisMark.string() }, textOrigin + FloatSize(0, emphasisMarkOffset)); else if (startOffset || endOffset < textRun.length() || !m_glyphDisplayList) m_context.drawText(font, textRun, textOrigin, startOffset, endOffset); else {
alan
Comment 5
2024-09-04 09:21:04 PDT
Maybe we use the wrong font? Seeing this FIXME comment in getEmphasisMarkGlyphData does not give me too much confidence. // FIXME: This function may not work if the emphasis mark uses a complex script, but none of the // standard emphasis marks do so. std::optional<GlyphData> FontCascade::getEmphasisMarkGlyphData(const AtomString& mark) const
yisibl
Comment 6
2025-10-28 05:15:29 PDT
Friendly ping
Karl Dubost
Comment 7
2025-10-28 06:18:22 PDT
The FIXME was added in
https://searchfox.org/wubkat/diff/4bfb080f7915539db5c634e19556417d75eee993/WebCore/platform/graphics/FontFastPath.cpp#200-202
in 2010.
https://bugs.webkit.org/show_bug.cgi?id=48539
(WebCore::Font::getEmphasisMarkGlyphData): Added. Returns glyph data for the first character of the emphasis mark. This function may not work if the emphasis mark uses a complex script, but none of the standard emphasis marks do so.
alan
Comment 8
2025-10-28 14:19:43 PDT
I did some debugging, and it looks like FontCascade::getEmphasisMarkGlyphData should be using a grapheme cluster iterator instead of the surrogate pair iterator we currently use. Elika/Vitor may have some insights here.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug