Track font cache, Base 14 matching, subsetting, and glyph parity

[erikbra]

Parent: #650

Upstream issues

• https://issues.apache.org/jira/browse/PDFBOX-6175 - Large CID font memory behavior.
• https://issues.apache.org/jira/browse/PDFBOX-2578 - Fuzzy matching of Base 14 fonts.
• https://issues.apache.org/jira/browse/PDFBOX-3759 - TTFSubsetter scrambles OpenType ligature/kerning tables.
• https://issues.apache.org/jira/browse/PDFBOX-4951 - Combining letters rendered incorrectly.

Current PdfBox.Net assessment

PdfBox.Net is mixed here:

• W2 vertical displacement ranges are already stored compactly.
• Direct font cache behavior still has memory-pressure risk.
• Base 14 mapping supports canonical names and common aliases, but not fuzzy suffix/name matching.
• Normal PDF font embedding drops advanced OpenType layout tables, which avoids one corruption mode but does not preserve those tables.
• New text creation through Skia glyph layout is stronger for Bidi/HarfBuzz shaping, but existing PDF rendering can still hit per-glyph/fallback limitations.

Next actions

• Track upstream font-cache and Base 14 matching decisions.
• Add fixtures for fuzzy Base 14 names and combining-mark rendering.
• Compare standalone TTFSubsetter behavior with Java before changing table preservation behavior.
• Keep HarfBuzz/Bidi improvements as accepted backend functionality, but do not use them to claim upstream bug closure without matching fixtures.

Acceptance criteria

• Each font/glyph issue has a documented applies/does-not-apply assessment backed by fixtures or source comparison.
• Any fuzzy Base 14 or subsetting behavior change follows upstream semantics unless explicitly accepted as a .NET adaptation.