fix: resolve core-14 font aliases to their standard metrics#294
Open
pablopupo wants to merge 1 commit into
Open
fix: resolve core-14 font aliases to their standard metrics#294pablopupo wants to merge 1 commit into
pablopupo wants to merge 1 commit into
Conversation
A PDF may reference a standard Type1 font by a common family alias such as Arial or Times New Roman and legally omit the /Widths table. The width resolver only matched when a canonical PostScript name (Helvetica, Times-Roman, ...) was a substring of the font name, so these aliases missed every bundled AFM and fell back to a flat 500 units/em. At 10pt that advances every glyph 5.00pt instead of the real width, leaving word bounding boxes about 20 percent too narrow and drifting progressively left in long strings. Bind the common Arial, Times New Roman and Courier New aliases to the core-14 metrics that PDF viewers substitute, so their advances come from the real Helvetica, Times and Courier AFM data. Fonts with an explicit /Widths table, and names that already contain a canonical family, keep their existing behavior. Signed-off-by: pablopupo <145598901+pablopupo@users.noreply.github.com>
Contributor
|
✅ DCO Check Passed Thanks @pablopupo, all your commits are properly signed off. 🎉 |
Contributor
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
Member
|
@pablopupo I have resolved already quite a few issues regarding this with the latest renderer. Can you attach here a PDF that does not work on main but that this PR solves? |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Standard Type1 fonts can be referenced by a common family alias like Arial or Times New Roman and legally ship without a /Widths table. docling-parse only found the bundled metrics when a canonical PostScript name (Helvetica, Times-Roman and so on) was a substring of the font name, so those aliases matched nothing and every glyph fell back to a flat 500 units/em. At 10pt that advances each character 5.00pt instead of its real width, which leaves word bounding boxes off and drifting further along the line the longer the string. On a 92 character Arial line the last glyph lands about 71pt away from where it should.
This is the remaining piece of #180. The canonical base-14 names from that report already resolve on current main (Courier gives the correct 6.00pt, Helvetica and Times-Roman give their real varying widths), so the change binds the Arial, Times New Roman and Courier New aliases to the Core-14 metrics that PDF viewers substitute. Arial now matches Helvetica glyph for glyph (A 6.67, W 9.44, i 2.22, m 8.33 at 10pt) instead of a flat 5.00. Fonts with an explicit /Widths table and names that already contain a canonical family keep their existing behavior, and a bundled real metric like ArialMT still wins over the alias. No new font data is added, the aliases reuse the Core-14 AFM files already shipped in pdf_resources.
Added tests/test_standard_font_widths.py, which builds its minimal PDFs in memory so it needs no external data. It covers Courier at 6.00pt, a proportional font with varying non-500 widths, the alias resolution for Arial and Times, and an explicit /Widths table taking precedence. The full test suite passes locally (81 passed).