Egy vonalkód nem egy kép, amellyel egy dokumentumot díszít. Ez egy mérés, és az olvasó (scanner) az a műszer, amely leolvassa azt. Ez az újraértelmezés (reframing) szinte mindent eldönt azzal kapcsolatban, hogyan kell belerajzolnia egyet a PDF-be. A vonalak (bars) nem hordoznak információt a feketeségükkel; az információ a vonalszélességek (bar widths) és a sorközszélességek (space widths) arányában él, és az olvasó ezt a tranzíciók időzítésével nyeri vissza, miközben egy lézer vagy érzékelő (sensor) végigsöpör rajtuk. Préselje össze ezt a geometriát, mossa el (blur), vagy zsúfolja tele a margóit, és olyan dolgot hoz létre, ami pontosan úgy néz ki, mint egy vonalkód, és úgy olvasható be, mint egy elmosódott folt (smudge). A HotPDF két lehetőséget kínál arra, hogy elhelyezzen egyet az oldalon, és a különbség közöttük pontosan az a különbség, ami e geometria irányítása (controlling) és feladása (surrendering) között van

Mit tud kódolni a HotPDF
A HotPDF lineáris (egy dimenziós) szimbólumokat (symbologies) rajzol, és a halmaz (set) szélesebb, mint amennyire a legtöbb projektnek szüksége van. A THPDFBarcodeType felsorolás (enumeration) lefedi a Code 2 of 5 családot annak interleaved, industrial és matrix formáiban; a Code 39-et és annak extended változatát; a három Code 128 részhalmazt (A, B és C); a Code 93 sima (plain) és kiterjesztett (extended) formáját; az MSI-t; a PostNet-et; a Codabar-t; a kiskereskedelmi UPC és EAN csoportot, nevezetesen az EAN-8-at, EAN-13-at, UPC-A-t, a tömörített (compressed) UPC-E0-t és UPC-E1-et, valamint a UPC kiegészítő 2 és 5 számjegyű kiegészítéseit (add-ons); továbbá a GS1-128 (EAN-128) részhalmazokat (subsets). Ez elegendő (enough) az ellátási lánc (supply-chain) címkéinek, a kiskereskedelmi értékesítési pontok (point of sale) és a raktárakban még mindig élő régebbi ipari kódok lefedéséhez
Amit nem rajzol le, az a kétdimenziós család (two-dimensional family). Itt nincs QR, Data Matrix vagy PDF417. Ezek bájtokat (bytes) kódolnak egy rácsban (grid), a saját hibajavító (error-correction) matematikájukkal, és ha egy követelmény megnevezi valamelyiket, ez a rossz eszköz, és ezt érdemes tudnia, mielőtt köré építene, nem pedig utána. Az egydimenziós kódok esetében a gyakorlati kérdés szűkebb: melyik szimbólum fogadja el a ténylegesen meglévő adatokat, mert a kódolások nem cserélhetők fel egymással (not interchangeable)
Az adatkorlátozások (data constraints) valósak, és a generálás (generation) idején harapnak. A Code 2 of 5 változatok és az MSI csak számjegyeket (digits) fogadnak el. A Code 39 nagybetűket, számjegyeket és egy maréknyi írásjelet (punctuation marks) hordoz; ha kisbetűkre vagy a teljes ASCII tartományra van szüksége, az a Code 39 Extended vagy egy Code 128 részhalmaz (subset). A Code 128C a sűrűség (density) érdekében két számjegyet pakol (packs) minden szimbólumba (symbol), így egy páros hosszúságú (even-length) numerikus karakterláncot (numeric string) kér, és semmi mást. Az EAN-13 tizenkét számjegyet vár, és a tizenharmadikat ellenőrzésként (check) számítja ki; az EAN-8 hetet vár, és a nyolcadikat számítja ki; az UPC-A tizenkettőt fogad el. Adjon egy szimbólumnak olyan adatot, amelyet nem tud reprezentálni, és nem kap egy hasznos kivételt (helpful exception), hanem egy olyan vonalkódot, amely szemetet (garbage) kódol, ami rosszabb, mert jól néz ki, amíg valaki be nem olvassa a kasszánál
Két rajzolási útvonal, a kontroll két szintje
A metódus (method), amelyhez a termelésben (production) nyúlni kell, a DrawBarcode, az oldalobjektumon (page object). Átveszi a szimbólumot, egy pozíciót, egy magasságot és egy olyan paramétert, amely a többinél is fontosabb: az MUnit-et, a modul szélességét (module width). A modul a legkeskenyebb vonal szélessége, az az atom, amelynek a kódban minden más méret a többszöröse, és itt pontokban (points) van kifejezve. Minden, ami azzal kapcsolatos, hogy a kinyomtatott eredmény beolvasható-e (scans), erre az egyetlen egész számra (integer) vezethető vissza
var
Pdf: THotPDF;
begin
Pdf := THotPDF.Create(nil);
try
Pdf.FileName := 'label.pdf';
Pdf.BeginDoc;
// BCType, X, Y, Height, MUnit (module width in points), angle,
// data, UseCheckSum, bar color, background color.
Pdf.CurrentPage.DrawBarcode(
bcCodeEAN13, // symbology
72, 680, // X, Y in points from the bottom-left
60, // bar height
1, // MUnit: 1pt narrowest bar
0, // no rotation
'123456789012', // 12 digits; the 13th is the check
True, // append the modulo-10 check digit
clBlack, clWhite); // bars black, background white
Pdf.EndDoc;
finally
Pdf.Free;
end;
end;
Két argumentum érdemel közelebbi vizsgálatot. A UseCheckSum hozzáfűzi (appends) a modulo-10 ellenőrző számjegyet (check digit), amelyet a szimbólum elvár, és a kiskereskedelmi (retail) kódok esetében ezt szinte mindig True-ra szeretné állítani; csak akkor kapcsolja ki, ha az adatai már hordoznak egy előre kiszámított ellenőrzést, különben egy dupla számjegyet kap. A vonal- (bar) és a háttérszínek (background colors) az utolsó két paraméter, és a kreativitás kísértése (temptation) egy olyan csapda (trap), amelyről az alábbiakban lesz szó. Vegye figyelembe a koordináta-origót (coordinate origin) is: mint minden más rajzolási hívásnál (drawing call) a HotPDF-ben, az X és az Y az oldal bal alsó sarkától mér pontokban (points), az Y pedig felfelé nő, ugyanazt a konvenciót követve, amelyet a Hello World példa is bemutat
A második út a DirectDrawBarcode, amely átveszi az adatokat és egy határolókeretet (bounding box), X, Y, Width, Height (X, Y, szélesség, magasság), és méretezi (scales) a vonalmintát (bar pattern), hogy kitöltse ezt a szélességet. Kényelmes (convenient) a kódok rácsra (grid) történő elrendezéséhez, mert megnevezi a lábnyomot (footprint), és a metódus a vonalakat (bars) ahhoz illeszti. Ez a kényelem egyben a veszélye (hazard) is. Ha megad neki egy szélességet, többé nem állítja be a modul méretét (module size); a metódus elosztja azt a helyet, amit engedélyez, annyi vonal (bar) között, amennyire az adatoknak szüksége van, és a legvékonyabb vonal azzá válik, ami ebből az osztásból (division) kijön. Kérjen egy sűrű Code 128 karakterláncot (string) egy túl keskeny dobozon belül, és a modulok csendben összezsugorodnak aszintre, amit már egyetlen olvasó (scanner) sem képes feloldani (resolve). Bármihez, aminek megbízhatóan beolvashatónak kell lennie, részesítse előnyben a DrawBarcode-ot, és állítsa be az MUnit-ot szándékosan. Tartsa fenn a DirectDrawBarcode-ot előnézetekhez (previews) és olyan elrendezésekhez, ahol már lemérte (measured), hogy az eredményül kapott vonalak olvashatóak maradnak (stay legible)
A modul szélessége egy felbontási döntés
Íme az aritmetika, amely meghatározza, hogy működik-e a címkéje. Egy lézerolvasó és egy kamera is rendelkezik egy olyan legkisebb jellemzővel, amelyet meg tud különböztetni, és a keskeny vonalnak nyomtatás után kényelmesen e felett kell landolnia. Az általános célú lineáris kódoknál (general-purpose linear codes) a széles körben idézett alsó határ (floor) a 13 mil keskeny vonal, vagyis kb. 0,33 mm, és sok kiskereskedelmi és ipari útmutató ezt inkább minimumnak, mint célpontnak (target) tekinti. Fordítsa le ezt PDF egységekre: egy pont az 1/72 hüvelyk (inch), nagyjából 0,353 mm, így egyetlen modul szélességű (module width) pont pontosan ezen az alsó határon ül. Ezért a MUnit := 1 a legkisebb érték, amiben meg kellene bíznia egy valódi olvasónak (scanner) szánt kód esetében, és ezért jelent a duplájára (2-re) emelése olyan margót (margin), amely szinte semmibe sem kerül egy olyan címkén, amelyen van még hely
Most kösse ezt össze a kimeneti felbontással (output resolution), mert a modulnak túl kell élnie a nyomtatót is. Egy 300 DPI-s lézernyomtatón egy eszközpont (device dot) 1/300 hüvelyk, így egy egypontos (one-point) modul körülbelül négy pont (dots) széles. Négy pont épphogy elegendő (barely enough) egy tiszta él (clean edge) rendereléséhez; a toner elkenődése (toner spread) és az enyhe illesztési hiba (registration error) beleeszik, és az a vonal (bar), amely a PDF-ben egy pontot mért, vastagabbra (fatter) vagy vékonyabbra (thinner) nyomtatódik ki, mint amit a specifikáció (spec) megenged. Növelje meg (bump) a modult 2 pontra, és nyolc ponttal tud dolgozni, ami elnyeli (absorbs) ezt a zajt. A belsővé teendő szabály: a pontokban (points) beállított modul szélességének a valós nyomtatási felbontáson (real print resolution) lévő eszközpontok (device dots) egész, kényelmes számának kell megfelelnie, nem pedig annak a felbontásnak, amellyel bárcsak rendelkezne. Egy kód, amely a képernyőről hibátlanul (flawlessly) olvasható, de a raktári nyomtatóról már nem, szinte mindig elbukott ezen az ellenőrzésen (check)
A nyugalmi zóna a szimbólum része
A leggyakoribb ok (single most common reason), amiért egy helyesen kódolt vonalkód (barcode) nem olvasható le (scan), a nyugalmi zóna (quiet zone), az a tiszta margó (blank margin) a vonalak (bars) két oldalán. Az olvasók (scanners) ezt az ürességet használják arra, hogy megtalálják, hol kezdődik és hol végződik a kód; e nélkül az olvasó nem tudja megkülönböztetni az első vonalat attól, ami mellette van az oldalon. A szabványok (standards) konkrétak. A legtöbb lineáris szimbólum (symbology) legalább tízszeres modulszélességű nyugalmi zónát kér mindkét oldalon, az UPC és EAN kiskereskedelmi (retail) kódok pedig baloldalt kilenc, jobboldalt pedig hét modult követelnek. Egy egypontos modullal ez nagyjából tíz pontot jelent, körülbelül egy heted hüvelyknyi, garantált fehér helyet (white space) a vonalak oldalán (flanking)
A HotPDF csak a vonalakat (bars) rajzolja meg, és semmi mást. Nem foglalja le (reserve) a nyugalmi zónát az Ön számára, ami azt jelenti, hogy a felelősség az Öné, és ezt könnyű elfelejteni. A hibamód (failure mode) trükkös (subtle): elhelyez egy vonalkódot egy táblázat cellaszegélyéhez (table cell border) simulva (flush), vagy hagyja, hogy az oldalelrendezés (page layout) egy logót (logo) zsúfoljon mellé, és a kód, amely egy üres oldalon minden teszten átment, abban a pillanatban leállítja a beolvasást (stops scanning), amint egy valódi dokumentumban (real document) kerül ki (ships). Tervezze meg a margót (margin) kifejezetten (explicitly). Mielőtt meghívná a DrawBarcode-ot, hagyjon legalább tíz modul szélességű üres helyet (clear space) mindkét oldalon, és kezeljen minden olyan grafikát (graphic), vonalat (rule) vagy szöveget, amely betolakodik ebbe a sávba (band), hibaként (defect), nem pedig kozmetikai választásként (cosmetic choice)
Szín, kontraszt, és az ember által olvasható sor
A vonal (bar) és a háttér (background) színei (colors) azért léteznek, hogy megfelelhessenek egy márka (brand) színpalettájának, és ez a leggyorsabb módja egy működő kód tönkretételének (break). Az olvasók (scanners) a kontrasztot olvassák le, klasszikusan vörös fénnyel, és sötét vonalakat várnak világos alapon. Fekete fehéren (black on white) az egyetlen kombináció, amihez tesztelés nélkül kellene nyúlnia. A sötétkék vagy sötétzöld a fehéren átmehet (pass); minden alacsony fénysűrűségű kontrasztú (low luminance contrast) megoldás, és különösen a piros vonalak, amiket a vörös fényű olvasó háttérnek (background) lát, nem fognak. Ha egy dizájner színes vonalkódokat (colored barcodes) kér, az őszinte válasz az, hogy a vonalak feketék maradnak, a szín pedig valahova máshova kerül a címkén (label)
A DrawBarcode útvonal az ember által olvasható szöveget is meg tudja jeleníteni (render) a vonalak (bars) alatt, azokat a számjegyeket, amelyeket az ügyintéző (clerk) gépel be, ha a leolvasás (scan) meghiúsul. Ez a szöveg egy tartalék (fallback), nem dekoráció, így amikor saját feliratát (caption) helyezi el, tartsa távol (keep it clear) a nyugalmi zónától; egy szimbólumcímke (label of the symbology), amelyet az oldalsó margóba (side margin) zsúfolnak, tönkreteszi ugyanazt az üres teret, amelyre az olvasónak (scanner) szüksége van. Az itteni példában szereplő mezők, beleértve a TextOut-ot minden környező címkéhez, ugyanazok a rajzolási hívások (drawing calls), amelyeket a jelentéskészítési kimeneti útmutató (report output guide) ismertet, ahová érdemes menni, amikor a vonalkód egy elem (element) egy nagyobb, összetett (composed) oldalon
Egy rövid ellenőrzési szokás
A vektoros vonalak (Vector bars) olyan előnyt jelentenek, amelyet érdemes megnevezni. Mivel a DrawBarcode a kódot PDF rajzoló operátorként (PDF drawing operators) írja fel raszteres kép (rasterized image) helyett, a vonalak élesek (crisp) maradnak bármilyen nagyítás (zoom) esetén, és a fájl nem hordoz saját felbontást (resolution); az egyetlen felbontás, ami számít, a nyomtatóé. Ez nem menti fel Önt a tesztelés alól, ez csak azt jelenti, hogy a tesztnek (test) papíron (on paper) kell történnie. Generáljon egy mintát (sample), nyomtassa ki a legalacsonyabb felbontású eszközön, amellyel a kódjai ténylegesen találkozni fognak, és olvassa le ugyanazzal az osztályú olvasóval (reader), amelyet a felhasználók a kezükben tartanak, ne pedig az íróasztalán lévő csúcskategóriás (high-end) képalkotóval (imager). Ellenőrizze a nyugalmi zónákat egy vonalzóval (ruler) a kinyomtatott példányon, erősítse meg (confirm), hogy a modulszélesség (module width) túlélte-e az utat a pontoktól (points) a képpontokig (dots), és ellenőrizze (verify), hogy a dekódolt (decoded) érték megegyezik-e azzal, amit Ön kódolt (encoded), ellenőrző számjeggyel (check digit) és mindennel együtt. Öt perc egy igazi olvasóval (real scanner) felfedi a fent leírt összes hibát, és még azelőtt, hogy egy raklapnyi (pallet) rosszul címkézett készlet megtenné
A DrawBarcode és a DirectDrawBarcode itt bemutatott metódusok a HotPDF Component részét képezik Delphi és C++Builder rendszerekhez