Skip to content

Conversation

@QuLogic
Copy link
Member

@QuLogic QuLogic commented Oct 3, 2025

PR summary

The only thing that expected this to work is Type 3 fonts in the PDF backend, but only to avoid an error when loading a range of characters (not all of which would be used.) This would introduce an odd behaviour in that load_char could never fail even if the glyph never existed. You would instead end up with the null glyph from the last font.

As of #30512, Type 3 fonts use load_glyph instead of load_char, with a glyph that we know exists (because it's from the limited subset character map we've created), or 0 for the null glyph. Thus no fallback is needed, and we can instead warn if not found, as the code seems to have originally intended.

PR checklist

@QuLogic QuLogic added this to the v3.11.0 milestone Oct 3, 2025
@github-project-automation github-project-automation bot moved this to Waiting for other PR in Font and text overhaul Oct 3, 2025
@QuLogic QuLogic moved this from Waiting for other PR to Ready for Review in Font and text overhaul Oct 3, 2025
The only thing that expected this to work is Type 3 fonts in the PDF
backend, but only to avoid an error when loading a range of characters
(not all of which would be used.) This would introduce an odd behaviour
in that `load_char` could never fail even if the glyph never existed.
You would instead end up with the `null` glyph from the last font.
@tacaswell tacaswell merged commit ad0b47a into matplotlib:text-overhaul Nov 6, 2025
41 of 42 checks passed
@github-project-automation github-project-automation bot moved this from Ready for Review to Done in Font and text overhaul Nov 6, 2025
@QuLogic QuLogic deleted the no-force-fallback branch November 20, 2025 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants