Bug 255298
| Summary: | Object replacement character (0xFFFC) generates null (0) glyph | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Vitor Roriz <vitor.roriz> |
| Component: | Text | Assignee: | Myles C. Maxfield <mmaxfield> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | gsnedders, mmaxfield, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Vitor Roriz
We are getting an empty glyphData object (thus a null glyph (0)) when the input character is the object replacement character (0xFFFC).
If such input is decorated with text-emphasis-marker, this will cause the marker not to be painted after https://github.com/WebKit/WebKit/pull/12471 is merged.
This is because, the null glyph gets replaced by the deleted glyph (0xFFFF) and after the PR is merged, we no longer will draw markers for associated deleted glyphs.
How to reproduce it:
<p class="foo">X</p>
.foo {
writing-mode:vertical-lr;
text-combine-upright:all;
text-emphasis:filled;
}
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/107897203>
Sam Sneddon [:gsnedders]
*** Bug 256372 has been marked as a duplicate of this bug. ***
Myles C. Maxfield
It's totally legit for characters to be mapped to the 0 glyph. The fact that the object replacement character gets mapped to the 0 glyph isn't a bug; it's expected.
If we recently added logic that says "the 0 glyph shouldn't get an emphasis mark" then that logic is wrong.
Myles C. Maxfield
Pull request: https://github.com/WebKit/WebKit/pull/14642
EWS
Committed 264886@main (aba48e65ac8b): <https://commits.webkit.org/264886@main>
Reviewed commits have been landed. Closing PR #14642 and removing active labels.