fix: prevent duplicate font family entries in FontFactoryImp

[garcia-d]

Description of the new Feature/Bugfix

FontFactoryImp.registerFamily appended a [familyName, fullName] pair to
its internal family list on every call, even when that exact pair was
already registered. Repeated registration of the same font grew the list
unboundedly and slowed down font lookup over time.

Guarded the insertion path with a contains check so the same
familyName/fullName pair is only ever added once. Applied identically to
both the legacy (com.lowagie) and modern (org.openpdf) FontFactoryImp
copies this branch ships, each with its own package-private
getRegisteredFamily accessor and unit test covering the deduplication
invariant.

Related Issue: none (found during code review, not tied to a filed issue)

Unit-Tests for the new Feature/Bugfix

• Unit-Tests added to reproduce the bug
• Unit-Tests added to the added feature

Compatibilities Issues

No behavioral change for callers - registerFamily still registers the
pair, just without duplicating it on repeat calls. No existing method
signatures changed; getRegisteredFamily is a new package-private
accessor, added only for the test, in both modules.

Your real name

Diego Garcia

Testing details

Added FontFactoryImpTest coverage for the dedup invariant in both
modules. Full test suite run locally with no regressions.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate failed

Failed conditions
41.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[codacy-production]

Not up to standards ⛔

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[garcia-d]

Hi @asturio,

This PR backports the font family duplicate-registration fix to the 2.4 branch. The same fix has been opened for every active branch: #1621 (1.3-java8), #1622 (1.4-java11), #1623 (2.0-java17), #1624 (2.2-java21), #1626 (master).

Heads up: the SonarCloud duplication gate is red here, but it's not a code-quality issue — this PR touches the legacy/modern mirror modules, which are near-identical by design, so the shared fix logic gets flagged as "duplicated" between them. There are zero actual Sonar issues (bugs/vulnerabilities/smells) on this PR.

Whenever you get a chance, I'd appreciate your review, and if it looks good, approval/merge into 2.4.

I'd also kindly ask, once merged, if an official release including this fix could be cut — particularly for the Java 8-compatible line (#1621), since I'd rather rely on an official release than patch it in locally.

Thanks for maintaining OpenPDF!