Only fallback to checking properties.widths for composite fonts with IdentityToUnicodeMaps in the hasGlyph helper function (issue 8570, issue 8255)
#8572
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
/botio test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/1ec23bb57e77871/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/975b635d118c4d4/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/1ec23bb57e77871/output.txt Total script time: 16.39 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/975b635d118c4d4/output.txt Total script time: 29.98 mins
|
…h `IdentityToUnicodeMap`s in the `hasGlyph` helper function (issue 8570, issue 8255) For `IdentityToUnicodeMap`s it doesn't make much sense to check if a particular `charCode` exists in the `toUnicode` map, since it includes all of them by design. However, completely ignoring missing glyphs for fonts with `IdentityToUnicodeMap`s caused glyph mapping issues in practice, so PR 5990 added a heuristic to instead check if a `width` entry existed for the glyph. The intention of that PR was that it should apply to `IdentityToUnicodeMap`s, but given how the code was (and still is) written it ended up applying to all composite fonts instead. This thus causes us to needlessly map a lot of glyphs, which since they are not found in the `toUnicode` map, results in us trying to move more glyphs than can actually fit into the Private Use Area. Hence why we end up with glyphs that fail to render successfully. *Hopefully we've got sufficient test coverage for this code!* As usual, I've successfully run all unit/font/reference tests locally with this patch. Fixes 8570. Fixes 8255.
Snuffleupagus
changed the title
properties.widths for composite font with IdentityToUnicodeMaps in the hasGlyph helper function (issue 8570)properties.widths for composite fonts with IdentityToUnicodeMaps in the hasGlyph helper function (issue 8570, issue 8255)
dannabanana34
approved these changes
Jun 26, 2017
dannabanana34
approved these changes
Jun 26, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please note: The commit message was updated to mention that the patch fixes two open issues, however no functional code changes were made!
For
IdentityToUnicodeMaps it doesn't make much sense to check if a particularcharCodeexists in thetoUnicodemap, since it includes all of them by design.However, completely ignoring missing glyphs for fonts with
IdentityToUnicodeMaps caused glyph mapping issues in practice, so PR #5990 added a heuristic to instead check if awidthentry existed for the glyph.The intention of that PR was that it should apply to
IdentityToUnicodeMaps, but given how the code was (and still is) written it ended up applying to all composite fonts instead.This thus causes us to needlessly map a lot of glyphs, which since they are not found in the
toUnicodemap, results in us trying to move more glyphs than can actually fit into the Private Use Area. Hence why we end up with glyphs that fail to render successfully.Hopefully we've got sufficient test coverage for this code!
As usual, I've successfully run all unit/font/reference tests locally with this patch.
Fixes #8570.
Fixes #8255.