fix: resolve core-14 font aliases to their standard metrics (2)#298
fix: resolve core-14 font aliases to their standard metrics (2)#298PeterStaar-IBM wants to merge 2 commits 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>
Signed-off-by: Peter Staar <taa@zurich.ibm.com>
|
✅ DCO Check Passed Thanks @PeterStaar-IBM, all your commits are properly signed off. 🎉 |
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/
|
…-14 alias style rows
|
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. |
fixed the rendering for the test-case!
superseding: #294