THotPDF.AssignSyntheticCodepointForGID / GetSyntheticCodepointForGID

THotPDF PUA synthetic codepoint allocator (v2.119.68)

Allokerer og spør etter syntetiske kodepunkter i Private Use Area (U+E000 - U+F8FF) for OpenType GSUB-substitut-GID-er som ikke har noe naturlig Unicode-kodepunkt tilgjengelig gjennom fontens cmap. Lukker hullet i produsentsidens GID-nivåutskrift som ble stående etter v2.119.43-66 GSUB-oppslags- og refinements-API-ene

Delphi-syntaks:

function AssignSyntheticCodepointForGID(GID: Word; out SyntheticCP: Word): Boolean;

function GetSyntheticCodepointForGID(GID: Word): Word;

Hvorfor API-et finnes

Den automatiske shaping-pipelinen på produsentsiden i v2.119.32-67 (arabisk / latin / devanagari) krever at substitutt-GID-er fra GSUB-motoren kan nås via et Unicode-kodepunkt - den eksisterende hex-kodede tekstpipelinen skriver kodepunkter, ikke GID-er, og leseren slår kodepunktet tilbake til et GID gjennom den innebygde /CIDToGIDMap. For substitutt-GID-er som har et naturlig Unicode-kodepunkt via fontens cmap (Arabic Presentation Forms, Latin Standard Ligatures FB00-FB06) fungerer den eksisterende pipelinen fint

Men fontspesifikke substitutter som havner på fontinterne GID-er - de fleste Devanagari-klyngformer, stilistiske alternativer som fontdesigneren bare leverer som nummererte GID-er, CJK-ideografiske variasjonssekvenser (IVS) og diskresjonære ligaturer uten tilsvarende Presentation Form - har ikke noe kodepunkt i det hele tatt i fontens cmap. Før v2.119.68 var disse GID-ene utilgjengelige gjennom produsentsidens hex-pipeline; v2.119.68 lukker dette hullet ved å la kallere tildele et syntetisk kodepunkt i Private Use Area for enhver GID

Semantikk for AssignSyntheticCodepointForGID

Allokerer neste ledige PUA-kodepunkt (startende ved U+E000) for det oppgitte GID-et og speiler tildelingen inn i hver cache som den eksisterende produsentside-hexpipelinen og leseroppløsningskjeden er avhengig av

1. FUnicodeCpToGid[SyntheticCP] := GID - slik at produsentsidens hex-pipeline sender ut SyntheticCP i tekstoperatoren og forbrukerleseren løser SyntheticCP tilbake til GID gjennom /CIDToGIDMap ved rendringstid

2. FAcroFormUnicodeAdvances[SyntheticCP] := em-fraction - slik at v2.65s linjebryter finner riktig hmtx-fremrykning for det syntetiske kodepunktet når det opptrer i AcroForm-tekstfeltinnhold

3. FUnicodeSyntheticCpForGID[GID] := SyntheticCP - den per-GID omvendte oppslagstabellen som brukes av GetSyntheticCodepointForGID for å gjøre gjentatte AssignSyntheticCodepointForGID-kall idempotente (det andre kallet med samme GID returnerer allerede tildelt SyntheticCP)

Returnerer True ved vellykket tildeling, med SyntheticCP satt til det allokerte kodepunktet. Returnerer False (og lar SyntheticCP stå på 0) under noen av disse defensive forholdene: ingen font registrert (RegisterUnicodeTTF aldri kalt eller kalt med tomme argumenter for å nullstille tilstanden), ugyldig GID (null eller utenfor cmap-ens glyftall), PUA-området oppbrukt (alle 6400 plasser U+E000 - U+F8FF allokert), cache ikke initialisert ved inndata

Semantikk for GetSyntheticCodepointForGID

En ren funksjonell spørring om en eksisterende tildeling. Returnerer det syntetiske kodepunktet som er allokert for GID hvis AssignSyntheticCodepointForGID(GID, ...) har blitt kalt tidligere; ellers returnerer den 0 (som ikke er et gyldig PUA-kodepunkt, så det fungerer også som en "ingen tildeling"-markør). Allokerer ikke. Trygg å kalle før noen AssignSyntheticCodepointForGID har kjørt

Livsløp for allokatorstatus

FUnicodeSyntheticCpForGID og markøren for neste ledige PUA (FUnicodeNextSyntheticCp) allokeres late ved første AssignSyntheticCodepointForGID-kall. Markøren starter på 0 (uinitialisert) og hopper til $E000 ved første allokering; senere allokeringer flytter den gjennom $E001, $E002, ..., $F8FF. Begge feltene tilbakestilles til tom / 0 ved hver RegisterUnicodeTTF('', nil) sammen med resten av per-font-underinndelingsstatusen, slik at kallere som gjenbruker en THotPDF-instans på tvers av flere dokumenter starter hvert dokument med en ny PUA-markør

Typisk arbeidsflyt (Devanagari-klyngform)

PDF.RegisterUnicodeTTF('NotoDeva', 'NotoSansDevanagari-Regular.ttf');

PDF.ShapingFeatures := [sfIndicShaping];

PDF.SetGSUBScript('deva');

// Get a font-internal cluster GID through the GSUB engine

ClusterGID := PDF.GetSingleSubstituteGlyph(BaseGID, 'nukt');

if ClusterGID <> BaseGID then

begin

  // Check if cmap reaches the substitute - usually no for Indic

  // clusters, since cluster GIDs are font-internal

  // Allocate a synthetic codepoint that the producer-side

  // hex pipeline can emit

  if PDF.AssignSyntheticCodepointForGID(ClusterGID, SyntheticCP) then

  begin

    // SyntheticCP is now in the U+E000-F8FF range; emit it

    // through UnicodeTextOut just like a normal codepoint

    PDF.CurrentPage.UnicodeTextOut(X, Y, 0, UnicodeChar(SyntheticCP));

    PDF.MarkUnicodeGlyphUsed(ClusterGID);

  end;

end;

Eksempel på idempotens

PDF.AssignSyntheticCodepointForGID(150, CP1);  // CP1 = $E000

PDF.AssignSyntheticCodepointForGID(151, CP2);  // CP2 = $E001

PDF.AssignSyntheticCodepointForGID(150, CP3);  // CP3 = $E000 (idempotent)

CP4 := PDF.GetSyntheticCodepointForGID(150);  // CP4 = $E000

CP5 := PDF.GetSyntheticCodepointForGID(999);  // CP5 = 0 (no assignment)

Atferd i forbrukerleseren

Leseren ser PUA-kodepunktet i tekstvisningsoperatoren og slår det opp gjennom den dokumentinnebygde /CIDToGIDMap til mål-GID-et, og renderer deretter det GID-et ved hjelp av det innebygde fontprogrammet. Fra leserens perspektiv er det ingen forskjell mellom et "naturlig" Unicode-kodepunkt som cmap ruter til GID og et syntetisk PUA-kodepunkt som /CIDToGIDMap ruter til GID - begge gir samme renderte glyf

Kopier / lim inn-atferd: PUA-kodepunkter går rundt som seg selv gjennom kopier / lim inn når ToUnicode CMap erklærer dem som identitetsmappinger. Kallere som vil at kildens Unicode-tegn (inngangssekvensen som produserte substituttet) skal gå rundt i stedet, kan registrere en omvendt mapping med RegisterToUnicodeReverseMapping eller skrive ActualText-egenskaper for markert innhold gjennom BeginTaggedContent og sende ut de syntetiske kodepunktene inne i det klamme innholdet. HotPDF bruker samme interne CID-mønster automatisk for RegisterUnicodeTTF-baserte AcroForm-utseendestrømmer som inneholder Unicode-tegn fra supplementarplanet

Avslutning av veikartet for fase 8

v2.119.68 / Phase 8c.6 avslutter veikartet for GSUB-motoren i fase 8: alle LookupType 1-8-spørrings-API-er (fase 1-6), API-et for valg av Script / LangSys (fase 7), inngangspunktet for lukking av TTF-underinndeling (fase 9), den statiske ligaturfoldingen etter passet (v2.119.32 / 58 / 60 / 62), den valgfrie automatiske pipelinen (v2.119.59), automatisk utsending av arabisk rlig + latin liga / clig + rclt (fase 8b / 8c.2 / 8b / GSUB 'rclt'), ToUnicode-omvendt mapping (v2.119.61 / 62 / 65), fremrykningsspørring (v2.119.64), Devanagari pre-pass for omlegging (v2.119.67) og nå utsending av PUA-syntetiske kodepunkter på GID-nivå (v2.119.68) samles i ett samlet formingsgrensesnitt på produsentsiden som håndterer alle typer substituttglyfer en OpenType-font kan produsere

Se også: OpenType GSUB-erstatningsmotor, Automatisk formings-pipeline (fase 8), Støtte for arabisk / persisk / urdu-forming, Støtte for syrisk / mongolsk / devanagari-forming, THotPDF.BeginTaggedContent