fix: updated the font-parsing

[PeterStaar-IBM]

The Problem

Your original change prioritized the encoding (MacRoman, WinAnsi, Standard, etc.) over the base font's built-in character mapping for ALL cases. This broke character resolution for fonts where the encoding was not explicitly specified in the PDF but defaulted to STANDARD.

For example, character code 16 in font F17 should map to ( using the font's built-in encoding, but your change was forcing it through StandardEncoding where character 16 is undefined, resulting in GLYPH<16>.

The Solution

The fix implements the correct PDF font encoding resolution order:

1. Differences array (highest priority - explicit character remapping)
2. ToUnicode CMap (if present)
3. Explicit encoding (if /Encoding or /BaseEncoding was specified in the PDF) ← Only when explicitly specified
4. Font's built-in encoding (for standard fonts when no explicit encoding)
5. Fallback to standard encoding

Changes Made

1. Added has_explicit_encoding flag to track whether encoding was found in the PDF
2. Updated init_encoding() in src/v2/pdf_resources/page_font.h:650 to set this flag
3. Updated get_correct_character() in src/v2/pdf_resources/page_font.h:493 to only prioritize encoding when it was explicitly specified

The test suite now passes completely, correctly handling both cases:

• Fonts with explicit encodings use the specified encoding
• Fonts without explicit encodings use their built-in character mappings

Fixes:

• MacRomanEncoding ignored when font matches known base font (e.g., Arial) #187.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

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)(?:\(.+\))?(!)?:

[github-actions]

✅ DCO Check Passed

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