Egy hiányzó glífa egy PDF-ben nem hiba. Az előállító olyan karaktert kér, amelyet a kiválasztott betű nem tud leképezni, a betű a nulla glífaindexet adja vissza, és a keletkező fájl szerkezetileg érvényes, mindenhol megnyílik, és üres dobozt mutat ott, ahol egy névnek vagy egy összegnek kellene lennie. Senki a generáló vezetékben nem tud meg. A címzett igen. A HotPDF bezárja azt a hurkot a TrackUnresolvedGlyphs tulajdonsággal: kapcsolja be, és a szövegrajzolási út minden olyan kódpontot rögzít, amelynek glífa-keresése nulla indexre oldódik fel, és OnUnresolvedGlyph eseményt vált ki egyedi találatonként egyszer, a kódponttal, a betűvel, amelyen elbukott, a szkripttel, amelyhez tartozik, és egy javaslattal azokat a betűket illetően, amelyek lefednék
A felismerés a válasz fele. A másik fele a SetFontFallbackChain, amely szkriptenként rendezett betűlistát regisztrál, tehát a közönséges esetek maguktól oldódnak meg, és csak a valódi rések jutnak el az Ön kezelőjéhez. Együtt egy olyan hibaosztályt alakítanak át, amelyet korábban az ügyfelek jelentettek, fordítás idején ellenőrizhetővé
Miért nem dob semmit egy hiányzó glífa?
Mert az ISO 32000 nem tesz kötelezettséget az előállítóra a lefedettség ellenőrzésére, és a nulla glífaindex törvényes glífa. Az a .notdef, amelynek körvonalát a betűtervező választja: általában üres vagy üreges téglalap, néha semmi. Egy megjelenítő, amely kirajzolja, helyesen viselkedik. A szövegkinyerés akár a helyes karaktereket is visszaadhatja, mert a /ToUnicode leképezést a forrásszövegből írják, nem a körvonalakból, tehát egy automatizált oda-vissza ellenőrzés boldogan átenged egy olyan dokumentumot, amelynek látható szövegében lyukak vannak
A gyakorlati következmény az, hogy a lefedettséget a rajzolás pillanatában kell ellenőrizni, amikor a függvénytár még tudja, melyik kódpontot kérték, és melyik glífát kínálta valójában a betű. Utána az információ elvész
A felismerőnek a részletkész állapotot kell figyelnie, nem az eszközkontextust
Itt rontotta el az első implementáció, és az ok megértése megéri, mert bármely szövegvezékre csavarozott lefedettség-ellenőrzésre igaz. A HotPDF-nek két szövegútja van. Az egyik regisztrált Unicode TrueType betűn át bocsát ki, regisztrációkor épített memóriabeli karaktertérképpel. A másik egy örökölt GDI út, amely minden karakterfuttatáshoz friss eszközkontextust és betűhandlet hoz létre
A lefedettség megítélése a GDI útból reménytelen. A leképezése nem az a leképezés, amely a kibocsátott tartalomfolyamba kerül, és a kettő nincs szinkronban, tehát a GDI eredményeket olvasó felismerő a teljes nyomtatható ASCII tartományt jelenti megoldatlanként. A tekintélyes válasz a regisztrált betűben lakik: az a karaktertérkép, amelyet a RegisterUnicodeTTF elemez, a GetUnicodeGlyphForCodepoint révén lekérdezve. A felismerő ezért a részletkész állapothoz van kapuzva, nem bármely GDI feltételhez, és egyszerűen nem fut azokon a dokumentumokon, amelyek soha nem regisztráltak Unicode betűt, ami helyes, mert azok a dokumentumok amúgy a standard kódolásokra korlátozódnak
Mellette egy második csapda ül. Egy betű GDI családneve és a regisztrációkor a betűbinárisból kinyert PostScript név különböző karakterláncok, és nem olyan módon, amelyet normalizálni lehetne: az Arial Unicode MS nevű család ArialMT PostScript nevet hordoz. Minden olyan kapu, amelyet úgy írtak, hogy „a jelenleg kiválasztott betű-e az, amelyet regisztráltunk”, név szerint hasonlít, halott kód, amely soha nem sül el. Kapuzzon állapotra, soha nem betűnevekre
Ne teszteljen glífafelismerőt emojival
A nyilvánvaló teszteset egy mosolygó arc, és meggyőzi majd, hogy a felismerő hibás. A csillagászati síkok közönséges emoji kódpontjai egy privát-használatú szintézisi úton oldódnak fel, amely közvetlenül glífaindexre képezi le őket, tehát soha nem érik el az általános lefedettségi ágat. A felismerő helyesen viselkedik, és a teszt a rossz utat méri
Használjon helyette hozzá nem rendelt kódpontot. Az U+0378 véglegesen kiosztatlan a Unicode-ban, tehát egyetlen betű sem képezheti le törvényesen, és pontosan azt az ágat gyakoroltatja, amelyet ellenőrizni szeretne. Az a megkülönböztetés a „a funkció hibás” és a „a teszt olyan bemenetet választott, amely megkerüli a funkciót” között valódi órákba kerül, és a kiosztatlan kódpontok a legolcsóbb mód annak elkerülésére
type
TCoverageAudit = class
private
FFindings: TStringList;
public
procedure Handle(Sender: TObject;
const Info: THPDFUnresolvedGlyphInfo);
property Findings: TStringList read FFindings;
end;
procedure TCoverageAudit.Handle(Sender: TObject;
const Info: THPDFUnresolvedGlyphInfo);
begin
// Egyedi kódpontonként egyszer sül el, nem előfordulásonként
FFindings.Add(Format('U+%.4X missing in %s (script %d), try: %s',
[Info.CodePoint, String(Info.FontName), Ord(Info.Script),
String(Info.SuggestedFonts)]));
end;
// Bekötése egy generáló feladatba
Pdf := THotPDF.Create(nil);
try
Pdf.TrackUnresolvedGlyphs := True;
Pdf.OnUnresolvedGlyph := Audit.Handle;
Pdf.RegisterUnicodeTTF('C:\Windows\Fonts\arial.ttf');
Pdf.BeginDoc;
Pdf.CurrentPage.SetFont('Arial', [], 11);
Pdf.CurrentPage.TextOut(50, 720, 0, CustomerName);
Pdf.EndDoc;
if Audit.Findings.Count > 0 then
// Hibáztassa meg a feladatot ahelyett, hogy dobozokkal teli oldalt szállítana
raise Exception.Create(Audit.Findings.Text);
finally
Pdf.Free;
end;
A tartalékláncok szkriptenként valók, nem betűnként
Az ok, hogy a tartalék szkript szerint van hatókörözve, nem forrásbetű szerint, az, hogy a lefedettségi rések írásrendszer szerint halmozódnak. Egy latin szövegbetűből hiányzik a dévanágari, a thai, a han és az emoji, egyszerre, és mindegyik helyettese más betű. Egy lánc deklarálása szkriptenként ezért a valós telepítést írja le: egy latin betű a törzsszöveghez, egy CJK betű, egy emoji betű, egy mindent fedő
// A THPDFFontScript lefedi a hfsCommon, hfsLatin, hfsGreek, hfsCyrillic,
// hfsHebrew, hfsArabic, hfsIndic, hfsSoutheastAsian, hfsCJK, hfsKana,
// hfsHangul, hfsEmoji és hfsOther értékeket
Pdf.SetFontFallbackChain(hfsCJK,
['Microsoft YaHei', 'SimSun', 'Yu Gothic']);
Pdf.SetFontFallbackChain(hfsArabic, ['Segoe UI', 'Arial']);
Pdf.SetFontFallbackChain(hfsEmoji, ['Segoe UI Emoji']);
Pdf.SetFontFallbackChain(hfsOther, ['Arial Unicode MS']);
A tartalék és a felismerés kiegészítik egymást, nem alternatívák. A láncok azt a lefedettséget kezelik, amelyet előre látott; a felismerő azt jelenti, amelyet nem, ami egy tetszőleges ügyféladatot feldolgozó rendszeren az érdekes fele. Vegye észre, hogy egy betű helyettesítése megváltoztatja a metrikákat, tehát egy tartalékra eső bekezdés átmostathat; ha az elrendezés számít, a helyettesített betű zárását és részletkészítési viselkedését érdemes elolvasni a betűrészlet-zárás cikkben, és az átrendezést vagy összekapcsolást igénylő szkripteket a komplex szkriptes szövegalakítás alakító szintje kezeli
Hogyan utólagosítható viselkedés a meglévő út veszélyeztetése nélkül
Ugyanaz a kiadás egy örökölt kern tábla tartalékot is hozzáadott a pártávolsághoz, és az, ahogyan azt hatókörözték, másolásra érdemes minta. Ahelyett, hogy új döntési pontot adott volna a kerning logikához, a tartalék arra a korai kilépési ágra akasztódik, amely már létezett a GPOS táblával nem rendelkező betűkért. Egy GPOS-szal rendelkező modern betű soha nem éri el, tehát viselkedése konstrukcióból változatlan marad, tesztelés helyett. Azok az utak, amelyek nem regisztrálnak Unicode betűt, két nulla offsetet produkálnak, tehát ők is változatlanok maradnak
Ez az alacsony kockázatú utólagos beépítés általános alakja egy érett renderelő függvénytárban: keresse meg azt az ágat, amely jelenleg semmit sem produkál, és tegye oda az új viselkedést. Az a „hisszük, hogy ez nem rontott vissza semmit” állítást „ez nem ronthatott vissza semmit” állítássá alakítja, ami sokkal jobb dolog egy olyan szövegmotorról mondani, amelyen más emberek számlái mennek át
Tegye kapuvá, ne naplóvá
A lefedettségi találatok csak akkor hasznosak, ha valami elbukik rajtuk. Egy dokumentumgeneráló szolgáltatásban a termékeny elrendezés az, hogy a követés menjen éjjeli regressziós feladatban valós ügyfélnevek, címek és termékleírások korpuszán, és a feladat bármely találaton bukjon meg. Mivel az esemény egyedi kódpontonként sül el, nem előfordulásonként, a kimenet kicsi marad olvashatóan akkor is, amikor egy egész szkript hiányzik
Termelésben ugyanaz a kezelő jobban szolgál telemetriaként: rögzítse a kódpontot és a betűt, szolgálja tovább a dokumentumot, és hagyja, hogy az összesítés megmondja, melyik szkriptet adja hozzá következőként a telepítési betűkészlethez. A beágyazott és helyettesített betűk renderelési viselkedését tovább tárgyalja a beágyazott betűglífák renderelése, és a teljes tulajdonságlista, a TrackUnresolvedGlyphs-szel együtt, a HotPDF Delphi PDF component terméklapon van dokumentálva