OpenType CFF annotation- og felt-appearances

De native appearance-buildere accepterer OpenType OTTO-fonts med CFF 1-outlines såvel som deres eksisterende TrueType-input

Plain-, rich-, shaped- og family tekst-appearances indlejrer hele det originale OpenType-fil gennem FontFile3 med Subtype OpenType og en CIDFontType0-efterkommer

Navne-nøglet CFF bruger glyph-indeks som CID'er, mens CID-keyed CFF bevarer sin faktiske Registry, Ordering, Supplement og charset-mapping fra glyph-indeks til CID'er

Den genererede Encoding CMap mapper teksttegnkoder til de faktiske CID'er; bredder bruger de CID'er, ToUnicode bevarer logisk tekst, og CIDFontType0 modtager ingen CIDToGIDMap

Glyph-positioner og udstrækninger bruger HarfBuzz OpenType-metrics, inklusive rich fragment- og combining mark-beggrundskanter; rich fragmenter deler uforanderlige per-style font-readers og én indlejret fontressource

CFF-metrics kræver et matchende arkitektur HarfBuzz-bibliotek, selv når ShapeComplexText er False; HOTPDF_HARFBUZZ_LIBRARY vælger en eksplicit sti, og kompleks shaping bruger derudover den eksisterende FriBidi-afhængighed

En synlig FreeText-annotation uden normal-appearance kan bruge en gyldig default-appearance-ressource indeholdende en komplet OpenType CFF-font; den eksisterende ressource-forrang, clipping, farver og skrivebeskyttet embedding-politik gælder

Redigerbar feltgenerering kræver stadig installérbar eller redigerbar tilladelse; skrivebeskyttet fallback tillader preview-and-print-tilladelse, mens begrænsede eller bitmap-kun outlines forbliver afvist, og no-subsetting bevarer hver originale fontbyte

Font-byte-, glyph-, objektstørrelses-, samlet rich-font-, cancellation- og native render-budgetter forbliver håndhævet; misdannede CFF INDEX-offsets, dictionaries, charset-intervaller, duplikerede CID'er og manglende samlingsstrenge afvises inden publicering

Format-mappingen følger ISO 32000-1:2008 9.7.4.2 og 9.9, inklusive den eksplicitte CID-keyed OpenType charset-mapping

Native rendering, MuPDF og Ghostscript består sparse-CID OpenType-fixturesne; de testede Poppler-backends har en separat sparse-CID OpenType mapping-inkompatibilitet, mens Poppler identity-CID OpenType og sparse rå CIDFontType0C-kontroller renderer korrekt

Uafhængige readers kan syntetisere en manglende annotation-appearance anderledes; eksplicitte genererede appearances tjekkes separat fra hver readers fallback-adfærd

Manglende annotation-appearances kan også beholde originale bare Type1-, Type1C- og CIDFontType0C-ressourcer gennem den originale raw-font annotation-sti; OpenType CFF2-input bruger den separate statiske default-instance appearance-backend med eksplicit formatkonvertering i stedet for at indlejre CFF2 direkte i en PDF 1.7 font-stream

Se HPDFBuildHeadlessTextAppearance og TryGetCompactFontTable