Canvas text and macOS font fixes#27548
Conversation
|
r? @pcwalton |
|
@bors-servo try |
Canvas text and macOS font fixes These changes work around a source of panics by skipping glyphs that don't exist when drawing text to the canvas. Ideally we would have font fallback and/or tofu characters, but that's a larger project than I wanted to get into right now. Relatedly, while investigating the non-panic errors observed in #27476, I realized that the underlying source of #24622 could be dealt with because we shouldn't actually need to open the CTFont by a file path to get the bytes, since we already have bytes available that we use to create the CTFont. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24622 and fix #27476 and fix the panic observed in #20445. - [x] There are tests for these changes
|
💔 Test failed - status-taskcluster |
|
@bors-servo try=wpt |
Canvas text and macOS font fixes These changes work around a source of panics by skipping glyphs that don't exist when drawing text to the canvas. Ideally we would have font fallback and/or tofu characters, but that's a larger project than I wanted to get into right now. Relatedly, while investigating the non-panic errors observed in #27476, I realized that the underlying source of #24622 could be dealt with because we shouldn't actually need to open the CTFont by a file path to get the bytes, since we already have bytes available that we use to create the CTFont. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24622 and fix #27476 and fix the panic observed in #20445. - [x] There are tests for these changes
|
💔 Test failed - status-taskcluster |
|
@bors-servo try=wpt-mac |
Canvas text and macOS font fixes These changes work around a source of panics by skipping glyphs that don't exist when drawing text to the canvas. Ideally we would have font fallback and/or tofu characters, but that's a larger project than I wanted to get into right now. Relatedly, while investigating the non-panic errors observed in #27476, I realized that the underlying source of #24622 could be dealt with because we shouldn't actually need to open the CTFont by a file path to get the bytes, since we already have bytes available that we use to create the CTFont. --- - [x] `./mach build -d` does not report any errors - [x] `./mach test-tidy` does not report any errors - [x] These changes fix #24622 and fix #27476 and fix the panic observed in #20445. - [x] There are tests for these changes
|
☀️ Test successful - status-taskcluster |
| continue; | ||
| }, | ||
| }; | ||
| start += advance * point_size / 24. / 96.; |
There was a problem hiding this comment.
Where do these values come from? Are you sure this isn't the units_per_em for some font?
There was a problem hiding this comment.
This is copied directly from the code we used to call in https://github.com/jrmuizel/raqote/blob/490bff22610a130ad75eb797b6bd6e3e361bbde5/src/draw_target.rs#L742-L761.
|
@bors-servo: r+ |
|
📌 Commit 1e743a7 has been approved by |
|
☀️ Test successful - status-taskcluster |
These changes work around a source of panics by skipping glyphs that don't exist when drawing text to the canvas. Ideally we would have font fallback and/or tofu characters, but that's a larger project than I wanted to get into right now.
Relatedly, while investigating the non-panic errors observed in #27476, I realized that the underlying source of #24622 could be dealt with because we shouldn't actually need to open the CTFont by a file path to get the bytes, since we already have bytes available that we use to create the CTFont.
./mach build -ddoes not report any errors./mach test-tidydoes not report any errors