A PDF nem ismeri a változó betűtípus fogalmát. A PDF-fájlba ágyazott betűtípus rögzített körvonalak és rögzített metrikák halmaza, ezért egy változó betűtípust egyetlen statikus példánnyá kell redukálni, mielőtt bekerülhetne egy dokumentumba. A HotPDF ezt a példányosítást belsőleg végzi el: megvizsgálod egy változó betűtípus tengelyeit, kiválasztasz olyan koordinátákat, mint a 620-as súly vagy a 87,5-ös szélesség, és a könyvtár ezeket az értékeket egy teljes, önálló betűtípus-programba süti bele, amelyet bármely szabványkövető PDF-olvasó meg tud jeleníteni
Ennek gyakorlati, nem elméleti oka van. A betűtervező cégek egyre gyakrabban egyetlen változó fájlt szállítanak tucatnyi statikus súly helyett, a tervezőcsapatok pedig olyan értékeket választanak, amelyeket egyetlen elnevezett példány sem kínál. Példányosítás nélkül a jelentéskészítő vagy visszaesik az alapértelmezett példányra, ami eldobja a tervezési döntést, vagy beágyazza a teljes változó betűtípust, és reméli, hogy a megjelenítő tiszteletben tartja azokat a tengelykoordinátákat, amelyekről nincs módja tudomást szerezni, amit pedig egyetlen olvasónak sem kötelező megtennie
Mit kell valójában újraépítenie a példányosításnak?
Egy OpenType változó betűtípus glifánként egy alapértelmezett körvonalat tárol, plusz egy, a tervezési térbeli pozíció szerint indexelt delta-készletet. Egy tengelykoordináta alkalmazása nem egyszerűen egy szám fejlécbe írása; azt jelenti, hogy végig kell járni a gvar táblát, interpolálni kell a deltákat a kért helyre, el kell mozgatni a pontokat, majd újra kell számolni mindent, ami ezekből a pontokból származott. A HotPDF újraépíti a glifakörvonalakat, a hosszú loca táblát, a teljes vízszintes és függőleges metrikákat, a globális betűtípus-határolókeretet és az sfnt ellenőrzőösszeg-korrekciót
Ugyanilyen fontos, hogy mi kerül eltávolításra. Egy statikus példány nem tarthatja meg az fvar, avar, gvar, HVAR, VVAR, MVAR, STAT vagy cvar táblákat, és egy elavult DSIG-nek is mennie kell, mivel az aláírt bájtok már nem léteznek. Ha bármelyiket bent hagyjuk, olyan betűtípus jön létre, amely változónak vallja magát, miközben már elmozgatott körvonalakat hordoz, a variációkat alkalmazó olvasók pedig ekkor másodszor is alkalmazni fogják azokat
Fantompontok, és a kétszeres alkalmazás csapdája
A teljes folyamat legfinomabb szabálya a metrikákat érinti. A gvar-ban egy glifa pontszáma lefedi a körvonalpontokat, illetve összetett glifa esetén a komponenspontokat, plusz négy fantompontot, amelyek a bal oldali oldaltávolságot, az előrehaladási szélességet és ezek függőleges megfelelőit kódolják. Ezekre a fantompontokra maguk is vonatkoznak deltaértékek
Így amikor egy betűtípusnak van gvar táblája, a HotPDF az interpolált fantompontokból vezeti le a vízszintes és függőleges metrikákat, és emellett nem alkalmazza a HVAR-t vagy a VVAR-t. Mindkettő hozzáadása a klasszikus hiba: ugyanaz a variáció kétszer kerül alkalmazásra, és minden előrehaladási szélesség kissé túl széles lesz, ami úgy jelenik meg, hogy a szöveg fokozatosan jobbra sodródik egy sorkizárt sorban. Csak akkor süti a könyvtár a metrikavariáció-tárolót közvetlenül a hmtx-be vagy a vmtx-be, ha a betűtípusnak nincs gvar táblája
Két további részlet tartja pontosan a geometriát. A fantompontok soha nem vesznek részt a kontúrinterpolációban, így az egyszerű glifáknál kifejezetten nem felsorolt pontokat kontúronkénti IUP-val következtetik ki, a fantompontok kizárásával. Az összetett glifák deltái pedig az XY-paramétereket használó komponens-eltolásokra kerülnek alkalmazásra, ami után a gyermek-határolókeretek rekurzívan újraszámolódnak. Ez a rekurzió mélységben korlátozott és ciklusellenőrzött, mert egy rosszindulatú vagy egyszerűen hibás komponensgráf ellenkező esetben végtelenül rekurzálhatna
A tervezési tér vizsgálata választás előtt
Bármely példányosítási munkafolyamat első hívása az InspectVariableFont, amely jelenti a tengelyeket és a betűtervező cég által definiált elnevezett példányokat. A tengelyrekordok tartalmazzák a négybájtos címkét, a minimum-, alapértelmezett és maximumértékeket, jelzőket és egy névazonosítót; az elnevezett példányok tartalmaznak egy alcsaládi névazonosítót, jelzőket, egy opcionális PostScript-névazonosítót és tengelyenként egy koordinátát:
var
Pdf: THotPDF;
Axes: THPDFVariableFontAxisArray;
Instances: THPDFVariableFontNamedInstanceArray;
I: Integer;
begin
Pdf := THotPDF.Create(nil);
try
if Pdf.InspectVariableFont('C:\Fonts\Inter.ttf', Axes, Instances) then
begin
for I := 0 to High(Axes) do
Writeln(Format('%s min=%.1f default=%.1f max=%.1f',
[string(Axes[I].Tag), Axes[I].MinimumValue,
Axes[I].DefaultValue, Axes[I].MaximumValue]));
Writeln(Format('%d named instance(s) defined', [Length(Instances)]));
end
else
Writeln('not a variable font - embed it as an ordinary TrueType face');
finally
Pdf.Free;
end;
end;A tengelytartomány jelentése azért fontos, mert a tengelyértékek a betűtípus által deklarált tartományhoz vannak korlátozva, nem a felhasználói felület által kínált tartományhoz. Egy csúszkát, amely lehetővé teszi a felhasználó számára, hogy 1000-es súlyt kérjen egy olyan betűtípuson, amelynek wght tengelye 900-nál megáll, a felületen kell korrigálni, nem csendben a betűtípus-rétegben, különben a nyomtatott kimenet nem fog egyezni az előnézettel
Koordináták kiválasztása és a dokumentum kiadása
A tengelyválasztás állapotfüggő, és az ezt követően regisztrált betűtípusokra vonatkozik. A SetVariableFontAxis egy négybájtos, nyomtatható ASCII címkét és egy véges értéket vár, és mindent, ami ettől eltér, kivétellel utasít el ahelyett, hogy csendben figyelmen kívül hagyná. A ClearVariableFontAxes visszaállítja a kiválasztást, a GetVariableFontAxisSelections pedig jelenti, hogy éppen mi van függőben, amit érdemes naplózni olyan jelentéskészítő motorokban, ahol több kódútvonal is hozzáférhetett ugyanahhoz a dokumentumobjektumhoz. Magát a családot a SetFont segítségével, név szerint választjuk ki, pontosan úgy, mint bármely más beágyazott TrueType betűkészletet:
begin
Pdf := THotPDF.Create(nil);
try
Pdf.BeginDoc;
Pdf.SetVariableFontAxis('wght', 620); // félkövér, nem elnevezett példány
Pdf.SetVariableFontAxis('wdth', 87.5); // enyhén keskenyített
Pdf.CurrentPage.SetFont('Inter', [], 11);
Pdf.CurrentPage.TextOut(72, 720, 0, 'Quarterly results');
Pdf.ClearVariableFontAxes; // vissza az alapértelmezett példányhoz
Pdf.CurrentPage.SetFont('Inter', [], 10);
Pdf.CurrentPage.TextOut(72, 700, 0, 'Prepared by the finance team');
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;Az OnVariableFontInstance esemény minden egyes példány létrehozásakor kiváltódik, és jelenti a felhasznált tengelyértékeket, ami a legolcsóbb módja annak, hogy naplóban bizonyítsd, egy adott PDF valójában mit tartalmaz. Mivel minden egyes eltérő koordinátakészlet eltérő betűtípus-programot eredményez, kezeld a tengelyválasztásokat a betűtípus-gyorsítótár kulcsának részeként; a gyorsítótárazás mechanizmusát a tartós betűtípus-részhalmaz gyorsítótár ismerteti
Hogyan hat egymásra a példányosítás a részhalmazolással és a formázással?
A példányosítás a részhalmazolás előtt fut le, és ez a helyes sorrend. A példányosított betűtípus egy normál statikus TrueType betűkészlet, így a szokásos részhalmazoló ugyanúgy kezeli, mint bármely mást: kiszámolja a glifazárványt, megtartja azokat a glifákat, amelyeket a dokumentum ténylegesen használ, és eldobja a többit. Az az összefüggés, amelyre figyelni kell, hogy ugyanazon család két különböző tengelyválasztása két különböző betűtípus-program, így egy olyan dokumentum, amely 400-as és 620-as súlyt is kever, két részhalmazt ágyaz be, nem egyetlen megosztott betűkészletet két példánnyal
A formázást elvben nem érinti, a gyakorlatban azonban érdemes ellenőrizni. Az elrendezési funkciók a GSUB-ban és a GPOS-ban élnek, amelyeket a példányosítás megőriz, így a ligatúrák és a stílusváltozatok továbbra is úgy működnek, ahogy azt az OpenType GSUB stílusváltozatok ismerteti. Ami változik, az a pozicionálás: egy keskenyített példány szűkebb előrehaladási értékekkel rendelkezik, mint az alapértelmezett, így minden olyan elrendezés, amely a példányosítás előtt mérte a szöveget, rossz szélességeket mért. Mérj ugyanazzal a tengelyválasztással, amellyel renderelni fogsz, és az eltérés megszűnik
Egy utolsó védekező megjegyzés az implementációból, hasznos mindenkinek, aki bővíteni kívánja ezt az útvonalat. A vertikális metrikák nélküli betűtípusok is kiértékelik a dinamikus tömb argumentumait a Delphi hívási helyén, így az elemzéskori tömbök mindig lefoglalódnak, ahelyett hogy egy HasVerticalMetrics ellenőrzésre támaszkodnának, amely egy üres indexen átlép. Ez az a fajta nyelvi szintű részlet, amely egy látszólag védett elágazást pontosan azokon a betűtípusokon alakít hozzáférési hibává, amelyekkel nem teszteltél
A változó betűtípus-támogatás ugyanabba a betűtípus-feldolgozási folyamatba illeszkedik, mint a beágyazás, a részhalmazolás és a glifazárvány, amelyet részletesebben a betűtípus-részhalmaz zárvány és formázott glifák ismertet. A Delphihez és C++Builderhez elérhető teljes tipográfiai funkciókészlet a HotPDF Delphi PDF-komponens oldalán található