Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Fallback '.notdef' Glyph for Improved Cross-Platform TrueType Font Support #1352

Merged
merged 14 commits into from
Jan 29, 2025

Conversation

spacegaori
Copy link

@spacegaori spacegaori commented Jan 24, 2025

I propose adding a fallback '.notdef' glyph for TrueType fonts. I encountered a similar issue to this one on macOS and Linux when attempting to use a system font, Times New Roman, for Unicode support. A key error was raised because the system fonts were missing the '.notdef' glyph. While the inclusion of this glyph is mandatory for TTF fonts, it is evidently not standardized across platforms. Instead of assuming the glyph’s existence, implementing a fallback option would improve cross-platform support and prevent these errors.

Checklist:

  • A unit test is covering the code added / modified by this PR

  • This PR is ready to be merged

  • In case of a new feature, docstrings have been added, with also some documentation in the docs/ folder

  • A mention of the change is present in CHANGELOG.md

@Lucas-C
Copy link
Member

Lucas-C commented Jan 24, 2025

Hi @spacegaori

Thank you very much for this PR 👍

Overall it seems a good idea to me, but I'll let @andersonhc have a look at this, because he's more expert on she subject of fonts than myself 😅

A couple of suggestions of minors changes to make to this PR before we accept it:

  • produce a warning in this case using LOGGER.warning (you'll find several examples in the code)
  • add a unit test (we will need a font without .notdef that is free for us to embed in this repo, right?)
  • add a mention of this to CHANGELOG.md file

@spacegaori spacegaori marked this pull request as ready for review January 25, 2025 00:17
@spacegaori spacegaori requested a review from gmischler as a code owner January 25, 2025 00:17
Copy link
Collaborator

@andersonhc andersonhc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job on this PR. I really like your solution


self.ttfont["glyf"][".notdef"] = pen.glyph()
self.ttfont["hmtx"][".notdef"] = (600, 0)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe having the fixed 0,0 to 600,600 would look weird on different fonts.
Maybe having your coordinates set to (ttfont['head'].xMin, ttfont['head'].yMax), (ttfont['head'].xMax, ttfont['head'].yMax) would generate a more consistent notdef outline.

"Fallback glyph will be provided."
) in caplog.text


Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Times New Roman is a commercial font owned by Monotype, so we can't include it in our repository.

I recommend getting a OFL font and renaming the .notdef glyph to something else to create your test font.

something like this:

from fontTools import ttLib

font = ttLib.TTFont("NotoSans-Regular.ttf")
glyphnames = font.getGlyphOrder()
glyphnames[0] = "dummy"
font = ttLib.TTFont("NotoSans-Regular.ttf")
font.setGlyphOrder(glyphnames)
post = font['post']
font.save("NotoSans-Regular-without-notdef.ttf")

Copy link
Author

@spacegaori spacegaori Jan 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post = font['post']

What does this line do?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post = font['post']

What does this line do?

If you don't read the 'post' table, fontTools will never apply the change on this table and the change won't be saved on the new font. It's because of the lazy loading they do to improve performance.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need to include the "NotoSans-Regular-without-notdef.ttf" - you can create the font and commit the ttf into the repository.

Also, the CI is failing because test/font/test_charmap.py will create a test file with the first 999 chars of every font on test/font, so you need to run it with generate=True once to create a reference file for the new font.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I'll run it once.

You don't need to include the "NotoSans-Regular-without-notdef.ttf" - you can create the font and commit the ttf into the repository.

Do you mean that I don't need to include the process of creating "NotoSans-Regular-without-notdef.ttf" and just include the created font?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't read the 'post' table, fontTools will never apply the change on this table and the change won't be saved on the new font. It's because of the lazy loading they do to improve performance.

Maybe it would be worth adding a comment explaining that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post = font['post']

FYI, this line causes a linter error.

test/fonts/test_add_font.py:158:4: W0612: Unused variable 'post' (unused-variable)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you included the TTF font already, I'd say just remove generating the font again (remove lines 151 to 161).

It should be good to merge after that.

@spacegaori spacegaori requested a review from andersonhc January 27, 2025 21:25
@andersonhc
Copy link
Collaborator

@allcontributors please add @spacegaori for code

Copy link

@andersonhc

I've put up a pull request to add @spacegaori! 🎉

@spacegaori
Copy link
Author

Linter fails on files that are not relevant to this PR 🤔

would reformat /home/runner/work/fpdf2/fpdf2/fpdf/annotations.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/enums.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/image_datastructures.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/line_break.py
would reformat /home/runner/work/fpdf2/fpdf2/scripts/benchmark_borb_vs_fpdf2.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/table.py
would reformat /home/runner/work/fpdf2/fpdf2/test/fonts/test_wraps_zerowidthspace.py
would reformat /home/runner/work/fpdf2/fpdf2/test/test_positioning.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/fpdf.py
would reformat /home/runner/work/fpdf2/fpdf2/test/text/test_varied_fragments.py

Oh no! 💥 💔 💥
10 files would be reformatted, 187 files would be left unchanged.

@andersonhc
Copy link
Collaborator

Linter fails on files that are not relevant to this PR 🤔

would reformat /home/runner/work/fpdf2/fpdf2/fpdf/annotations.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/enums.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/image_datastructures.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/line_break.py
would reformat /home/runner/work/fpdf2/fpdf2/scripts/benchmark_borb_vs_fpdf2.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/table.py
would reformat /home/runner/work/fpdf2/fpdf2/test/fonts/test_wraps_zerowidthspace.py
would reformat /home/runner/work/fpdf2/fpdf2/test/test_positioning.py
would reformat /home/runner/work/fpdf2/fpdf2/fpdf/fpdf.py
would reformat /home/runner/work/fpdf2/fpdf2/test/text/test_varied_fragments.py

Oh no! 💥 💔 💥
10 files would be reformatted, 187 files would be left unchanged.

I think a new version of Black is changing what it checks. However Lucas already merged #1354 performing the changes. You can just sync or rebase your fork with the new commits and that should be all.

@andersonhc andersonhc merged commit d07a6a7 into py-pdf:master Jan 29, 2025
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants