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 thatload_char could never fail even if the glyph never existed. You would instead end up with thenull glyph from the last font.

As of#30512, Type 3 fonts useload_glyph instead ofload_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

[n/a] "closes #0000" is in the body of the PR description tolink the related issue
new and changed code istested
[n/a]Plotting related features are demonstrated in anexample
[n/a]New Features andAPI Changes are noted with adirective and release note
[n/a] Documentation complies withgeneral anddocstring guidelines

QuLogic added this to thev3.11.0 milestone

Oct 3, 2025

QuLogic added this toFont and text overhaul

Oct 3, 2025

QuLogic added the Maintenance label

Oct 3, 2025

github-project-automationbot moved this toWaiting for other PR inFont and text overhaul

Oct 3, 2025

QuLogic moved this fromWaiting for other PR toReady for Review inFont and text overhaul

Oct 3, 2025

github-actionsbot added the topic: text/fonts label

Oct 3, 2025

Remove forced fallback from FT2Font::load_char

a47bd3f

The only thing that expected this to work is Type 3 fonts in the PDFbackend, but only to avoid an error when loading a range of characters(not all of which would be used.) This would introduce an odd behaviourin 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.

QuLogic force-pushed theno-force-fallback branch from39c8238 toa47bd3fCompare

October 23, 2025 08:34

QuLogic added the status: needs review label

Oct 24, 2025