Benannte Rich-Text-Schriftfamilien
Native Rich-Felder können bis zu sechzehn gelieferte Unicode-TrueType-Schriftfamilien kombinieren, jeweils mit Regular-, Bold-, Italic- und Bold-Italic-Programm; jeder ausgewählte Run nutzt seine echten Font-Bytes, Glyphen-Zuordnung, Breite, Grundlinie und Marken-Geometrie
Konfigurieren Sie THPDFHeadlessRichTextFontFamilies, weisen Sie das FontFamily-Label jedes Runs zu und rufen Sie SetRichTextFieldValueWithFamilies auf; ein leeres Run-Label wählt die erste konfigurierte Familie
Für XHTML setzen Sie FontFamilyNames und die Default-Run-Familie vor dem Dekodieren; kommagetrennte Schriftfamilienlisten mit oder ohne Anführungszeichen wählen das erste konfigurierte Label, inherit stellt die umgebende Familie wieder her, und gültige important-Deklarationen behalten ihre Priorität
Eine gültige Liste ohne konfiguriertes Label wählt die erste konfigurierte Familie; eine missgebildete Deklaration lässt den vorherigen Wert unverändert; der Abgleich faltet ASCII-Buchstaben und bewahrt andere Unicode-Zeichen exakt
Labels enthalten höchstens 128 UTF-16-Code-Einheiten, ohne umgebende Leerzeichen, Steuerzeichen, unpaired Surrogates, Anführungszeichen, Backslashes, Kommas oder Semikolons; dieses begrenzte Profil implementiert keine CSS-Escapes und keine implizite Systemfont-Suche
Der reine Family-Appearance-Builder bettet nur ausgewählte Stile ein und legt aggregierte Font-, Glyphen-, Objekt-, Byte- und Abbruchbudgets an; fehlende ausgewählte Schriften und unbekannte explizite Run-Labels schlagen fehl, bevor Dokumentänderungen committet werden
Familienbewusster Formularimport wendet dieselbe Auswahl auf echte FDF-RV- und XFDF-value-richtext an, bewahrt bestehende Feld- und Signaturpolicys und vergleicht kanonische benannte Rich-Werte für semantische No-Ops
Die bestehenden Single-Family-APIs und das Default-Decoder-Profil behalten ihre Signaturen und ihr Verhalten; Programme mit regenerierten Pascal- oder C++Builder-Headern müssen neu übersetzt werden, wenn sie die erweiterten managed Run- und Option-Records übernehmen; die externen V1-C-ABI-Records bleiben unverändert
Native Linux named-family JSON und versionierte C-ABI-Auswahl sind über die Linux-Family-Bindung verfügbar; Windows-FDF- und XFDF-Jobs akzeptieren verschachtelte Familien-/Stildateipfade oder bestehende V1-Font-Callbacks über Windows form-data exchange
Opt-in Supplied-Family-Grapheme-Fallback wählt echte Kandidatenfamilien- und -stilprogramme über die nativen APIs; Linux-JSON-Fallback löst die benötigten konfigurierten Kandidatenprogramme auf, bevor dieselbe Appearance aufbereitet wird
Beliebige CSS-Escapes, implizite Systemaliase, externe Style Sheets, allgemeines CSS-Layout, Windows-typisierte Rich-Job-Auswahl und Windows-Callback-Fallback-Laden bleiben laufende Arbeit
Abnahme
Sechs native Compiler-Ziele bestehen 168 Assertions und 1327 unabhängige Prüfungen über je 36 tatsächlich gespeicherte PDFs pro Ziel, darunter acht echte Font-Programme, Mixed-Family-Advances, Unicode-Labels, geerbte Priorität, FDF-/XFDF-Import, AES R5/R6-Sicherheit, Rollback sowie frühe oder späte Abbrüche
Frische C++Builder-Header übersetzen die neuen Familien-Records, Builder und Dokumentmethoden auf beiden Architekturen; beide versionierten Linux-Shared-Libraries bestehen nach dem Neubau mit den neuen internen Records die bestehenden Vier-Font-Callbacks und unabhängigen Ausgabeprüfungen