Skip to content

fix: resolve core-14 font aliases to their standard metrics (2)#298

Open
PeterStaar-IBM wants to merge 2 commits into
mainfrom
fix/180-standard-font-widths
Open

fix: resolve core-14 font aliases to their standard metrics (2)#298
PeterStaar-IBM wants to merge 2 commits into
mainfrom
fix/180-standard-font-widths

Conversation

@PeterStaar-IBM

@PeterStaar-IBM PeterStaar-IBM commented Jul 11, 2026

Copy link
Copy Markdown
Member

fixed the rendering for the test-case!

Screenshot 2026-07-11 at 07 37 02

superseding: #294

pablopupo and others added 2 commits July 5, 2026 00:48
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>
Signed-off-by: Peter Staar <taa@zurich.ibm.com>
@github-actions

Copy link
Copy Markdown
Contributor

DCO Check Passed

Thanks @PeterStaar-IBM, all your commits are properly signed off. 🎉

@mergify

mergify Bot commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

  • title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

@PeterStaar-IBM PeterStaar-IBM changed the title Fix/180 standard font widths fix: 180 standard font widths Jul 11, 2026
@PeterStaar-IBM PeterStaar-IBM changed the title fix: 180 standard font widths fix: resolve core-14 font aliases to their standard metrics (2) Jul 11, 2026
pablopupo added a commit to pablopupo/docling-parse that referenced this pull request Jul 11, 2026
@pablopupo

Copy link
Copy Markdown
Contributor

core14-alias-no-widths-extended.pdf

Here it is. One page with thirteen lines, one per row of the alias table, arial, couriernew, times and timesnewroman in regular, bold, italic, and bolditalic. It's the same construction as before where every font with no /Widths and no FontDescriptor, and each line starts with the BaseFont it exercises so a render is easy to eyeball. I verified every line on this branch against the matching AFM, the widths and the per-glyph advances both match to the third decimal.

Note that on main before #294 the nine non-courier lines collapse to the flat 500 fallback, but the courier ones already read 7.2pt there since couriernew substring-matches courier and every Courier style is 600 units wide, so asserting per-glyph advances catches more than asserting the width changed. Also the BaseFont spellings are the exact alias keys on purpose, producer names like Arial-BoldMT would longest-match the bundled Microsoft AFMs instead of the alias rows.

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.

2 participants