GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||
GeezerVison is showing github.com — Use glyph indices for font tracking in vector formats by QuLogic · Pull Request #30335 · matplotlib/matplotlib Conversation
|
|
I've decided to restore the character code in the return values from mathtext, because I've found some use for it in PDF output. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
df7fa98 to
8de7f4e
Compare
With libraqm, string layout produces glyph indices, not character codes, and font features may even produce different glyphs for the same character code (e.g., by picking a different Stylistic Set). Thus we cannot rely on character codes as unique items within a font, and must move toward glyph indices everywhere.
8de7f4e to
f630b48
Compare
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Looks like mypy is unhappy for unrelated reasons (beyond the disjoint bases issues) so that can probably be fixed as a separate PR.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I've rebased #30512 as well now. Of course, I wrote the change much after this one, but now it does seem like they go together quite well, so let me know if you want me to move the "pdf/ps: Track full character map in CharacterTracker" commit here to review together. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I don't really mind either way, the advantage of splitting things in smaller chunks is that once a PR is done we can just forget about it and move on to the next one (whereas if you add another patch here there's no easy way to state "the first commit is ready to go but the second still needs review"). More specifically, it seems to me that the UI of github is not really optimal in that reviews (and the approval process) are "PR-oriented" whereas for these large, multi-step PRs, it would be useful to have "commit-oriented" reviews. Given the current limitations I would suggest splitting the charmap tracking commit into its own PR (on top of this one) as well as I suspect (no guarantees) that it can also be approved quickly. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Edit: I reviewed that commit and would approve it except for the two doc-related comments I've left. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
OK, I split that into #30566, and fixed the comments as well. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Use glyph indices for font tracking in vector formats
It wasn't updated to handle the change to `VectorParse` in #30335.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.