Skip to content

Map glyph names with suffixes or ligature components to Unicode (issue 22410) - #22411

Closed
fushanbobfan wants to merge 1 commit into
mozilla:masterfrom
fushanbobfan:glyph-name-suffixes
Closed

fushanbobfan wants to merge 1 commit into
mozilla:masterfrom
fushanbobfan:glyph-name-suffixes

Conversation

@fushanbobfan

Copy link
Copy Markdown

Fixes #22410

When a simple font has no ToUnicode entry for a code, its text comes from the glyph name. Names such as c.sc, T_h.alt and uni00E9.sc were looked up whole, matched nothing, and the code was then read as its own character, so the word drawn as "nicht" in the issue's file was extracted as "ni!ht".

When none of the existing lookups give a mapping, the name is now mapped as described in section 2 of the Adobe Glyph List Specification: everything from the first period on is dropped, the rest is split at underscores, and each component is mapped through the glyph list, as a uni name with one or more groups of four hexadecimal digits, or as a uXXXX{XX} name. The result is only used when every component maps, so names like cid_12 remain unmapped. The existing lookups, including the Cdd{d} handling and its re-parse, run first and are unchanged.

Testing:

  • New api_spec.js test with issue22410.pdf, the reduced file attached to the issue: getTextContent gives ni!ht "e caf# on master and nicht The café with this patch.
  • New unicode_spec.js cases for the helper (suffixes, ligature components, multi-group uni names, and names that must stay unmapped, such as cid_12, lowercase hex and surrogates).
  • The existing issue 10640 test expected \x81, \x82 and \x80 where the page shows "1", "2" and "0"; that font's figures are named one.os, two.os, zero.os and so on, so the expectations now contain the digits.
  • npx gulp unittestcli on Windows: 1806 specs, 0 failures, 82 pending; npx eslint and npx prettier --check pass on the changed files.
  • I did not run the reference tests locally. As the issue notes, non-embedded non-standard fonts build toFontChar from toUnicode, so fonts whose glyph names now map may draw a different substitute glyph in the ref tests.

…e 22410)

When a simple font has no ToUnicode entry for a code, its text comes from the
glyph name. Names such as `c.sc`, `T_h.alt` and `uni00E9.sc` were looked up
whole, matched nothing, and the code was then read as its own character, so
the word drawn as "nicht" was extracted as "ni!ht".

When none of the existing lookups give a mapping, the name is now mapped as
described in section 2 of the Adobe Glyph List Specification: everything from
the first period on is dropped, the rest is split at underscores, and each
component is mapped through the glyph list, as a `uni` name with one or more
groups of four hexadecimal digits, or as a `uXXXX{XX}` name.
The result is only used when every component maps, so names like `cid_12`
remain unmapped.

This also fixes the figures in issue10640.pdf, whose glyphs are named `one.os`,
`two.os` and so on; the unit test expected them as "\x81", "\x82" and "\x80".
@Snuffleupagus

Copy link
Copy Markdown
Collaborator

Sorry, but that issue really does not seem like a good fit for a first-time contributor who appears to just submit fully AI generated code (even more so when according to #22411 (comment) you didn't even bother running the full test-suite).

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.

[Bug]: Text of an embedded simple font is read as the code's own character when the glyph name has a suffix (c.sc) or is an unknown ligature (T_h.alt)

2 participants