Az örök kérdés: Type 1? True Type? Open Type?

Igen, az egyik leggyakoribb, olykor vallásháborúhoz is vezető kérdés - álljunk hát neki alaposan, vizsgáljunk meg minden részletet - kezdve egy kis történeti kitekintéssel.

Amerika felfedezése előtt

Az egyes betűtípusokat többféle formátumban is tárolhatjuk a számítógépben. Nemrégen, az olcsóbb-egyszerűbb lézernyomtatók korában, az egyes betűk képét pixelekre lebontva tároló bitmap fontokat ismertük csak. Ez a formátum bizonyos értelemben a lehető legjobb, hiszen közvetlenül, mindenféle átalakítás nélkül küldhetjük a képernyőre vagy a nyomtatóra a betűt leíró képpontokat. További előnye, hogy a raszterré bontott betűket gondosan, nagy számításigényű optimalizáló eljárásokkal vagy kézzel tökéletesíthetjük, ily módon olyan szép betűképet érve el, amelyet a nyomtatás közben röptében elvégzett konverzió nem vagy nagy áldozatok árán tud csak létrehozni. Ezen előnyökkel szemben viszont több jelentős hátránnyal is meg kellett küzdeni: minden felbontáshoz, betűváltozathoz, mérethez külön fontfájl tartozott, amelyek helyfoglalása a betűméret négyzetével arányosan nőtt. Emiatt csak kevés betűtípusból, mindössze néhány különböző méretet lehetett csak célszerűen tárolni - figyelembe véve az akkoriban szokásos legfeljebb 20-40 megabájtos vincsesztereket is. Ráadásul, a nagyméretű fontokat a nyomtatóba letölteni jelentős időbe telt. A DTP robbanásszerű terjedésével hamarosan szükségessé váltak az ennél takarékosabb megoldások. Kézenfekvő ötletnek ígérkezett, hogy ne az egész betűt tároljuk, csak a körvonalát (méghozzá annak sem minden egyes pontját, hanem megpróbáljuk a körvonalat általánosabb matematikai módszerekkel leírni), és a nyomtatóra (vagy megfelelő programra) bízzuk, hogy ebből kiszámítsa a megjelenítéshez szükséges pixeleket. Ennek legegyszerűbb módszere - amely a kezdeti képernyős kijelzőknél és a plottereknél terjedt el - egyenes vonalszakaszokra bontotta fel a betű körvonalát. Mivel a szokásos betűtípusok számos ívelt vonalat is tartalmaznak, ezeket sok kis egyenes szakasszal kell megközelítenünk. Kényelmesebben és kevesebb adat felhasználásával írhatjuk le tehát a körvonalakat, ha ez utóbbi részeket inkább körívszakaszokkal próbáljuk megadni. Mivel azonban a legtöbb betűtípus íves szakaszai nem illeszkednek körívre, tehát csak több körívdarabka egymás után illesztésével tudjuk valamelyest megközelíteni őket. Ráadásul - amint az némi matematikával egyszerűen belátható - az egyes körívdarabok csatlakozási pontjaiban nehéz lesz elkerülni a körvonal megbicsakló illeszkedését. Éppen ezért jó lenne a körív helyett olyan görbefajtát találnunk, amely kevés adattal leírható, tetszetősen sima görbe vonalakat rajzol, és a szomszédos görbeszakaszok megbicsaklás nélkül, simán kapcsolódnak egymáshoz. Szerencsénkre, a spline-nak nevezett görbék megfelelnek ezeknek a kívánalmaknak. A régi hajóépítők hosszú fabordákat erősítettek a hajó vázára úgy, hogy azokat meghatározott helyen a vázhoz erősítették, és a felerősítési pontok között a fa rugalmasságának megfelelően az előre megtervezett görbületet vette fel; az angol hajóépítő nyelv spline-nak [ejtsd: szplájn] nevezi ezt a fabordázatot. És mivel az említett görbék ugyanígy viselkednek (átmennek a meghatározott pontokon, akárcsak a fa a felerősítési helyeken; a pontok között magától beáll a megfelelő görbület, akárcsak a fánál; a görbevonal végig sima görbületű, akárcsak a fa, amíg el nem törik; a felerősítési pontok helyes megválasztásával el lehet érni, hogy a szomszédos görbeszakaszok, akárcsak a szomszédos bordák, finoman illeszkedjenek egymáshoz), nem véletlenül kapták ők is a spline nevet. A numerikus analízisben járatosaknak: a spline-interpoláció az interpoláló közelítések egy fontos válfaja. Az n-edrendű spline olyan függvény, amely a közelítendő függvény értelmezési tartományát intervallumokra bontva, mindegyik intervallumban egy-egy n-edfokú polinommal közelíti az eredeti függvényt, úgy, hogy az intervallumok végpontjaiban a két szomszédos polinom deriváltjai az n-1-edik rendűig bezárólag folytonosak. Harmadfokúnál alacsonyabb rendű spline tehát nem tudja biztosítani, hogy a szomszédos szakaszok simán kapcsolódjanak egymáshoz. A DTP-gyakorlatban a spline-t nem közelítésnek, hanem a betűkörvonalat leíró tényleges függvénynek tekintjük, és a kinyomtatás során őt közelítjük lineáris vagy egyéb interpolációval.

A két formátum kialakulása

A PostScript betűkészletek a nevüket adó általános, platformfüggetlen oldalleíró nyelvvel együtt, a True Type-ot mintegy hat évvel megelőzve jelentek meg az 1985-ben piacra került Apple LaserWriter lézernyomtatóban. Az Adobe [ejtsd: edobi] által kifejlesztett nyelv akkor még csak egy volt a számos egyéb oldal- és fontleíró formátum közül, amelyek egyike sem jutott el korábban az általános felhasználásig, a szabványosulásig. A nyomtató sikere, a DTP terjedése és a PostScript elfogadottá válása a drága filmlevilágító berendezésekben azonban a nyelv széleskörű elterjedéséhez vezetett. A PostScript nyelv ugyan kezdettől fogva nyilvános és bárki számára hozzáférhető volt, a fontformátum titkát az Adobe sokáig féltékenyen őrizte (pontosabban, csak a Type 1 fontokét, hiszen a Type 3 ismertetése szerepelt a PS leírásában; ez utóbbi formátumnak ugyan vannak előnyei, de kisebb felbontású berendezéseken - az akkori 300 dpi-s lézernyomtatókon - rosszabb minőséget nyújtott). Rövidesen nyilvánvalóvá vált, hogy a körvonalas - tehát tetszőleges pontméretben egyenletes minőségben megjeleníthető - betűkészletekre a kialakulóban levő, grafikus felhasználói felületű operációs rendszerekben nagy szükség lesz. Az ilyesmiket fejlesztő cégek (a Microsoft, az Apple és az IBM) azonban nem szívesen használták volna fel mások rendszerét erre a célra, félve a külső befolyástól. Az Apple tehát nekiállt kifejleszteni saját rendszerét - ezt ismerjük ma True Type néven. Később az Apple és a Microsoft egymás rendelkezésére bocsátották megoldásaikat (a Microsoftnak volt egy nem túl sikeres PostScript-utánzata, ez volt a cserealap), és ennek keretében a True Type formátum nyilvánosságra került. Lépéskényszerbe kerülve, az Adobe is a Type 1 formátumának felszabadítása mellett döntött, majd röviddel ezután megjelent az Adobe Type Manager programjuk is, amely a Windows 3.1 alatt a PostScript fontok képernyőn történő megjelenítését, valamint nem-PostScript nyomtatókon kinyomtatását tette lehetővé a Windowsba beépített True Type fontok mellett. Kezdetben a True Type egyeduralkodó volt az általános felhasználású számítógépeken, míg a Type 1 fontok kimondottan a DTP-vel foglalkozók és a drága, levilágító rendszerek kiváltsága volt. Az idő haladtával azonban a különbségek kezdenek elmosódni. Sok PostScript 2-es készülékbe már a True Type fontok támogatását is beépítették, a PostScript 3-asokban pedig már mindenképpen benne van.

Mi tehát a különbség?

A Type 1 fontok - akárcsak a PostScript nyelv maga - a Bézier francia mérnök nevét viselő, harmadfokú spline-okkal írják le a görbe vonalakat. Ezt a görbetípust a mérnök úr a Renaultnál találta ki, ahol a szélcsatorna-kísérletekhez és számítógépes modellezésükhöz szintén szükség volt az autók görbült formáját hatékonyan leíró matematikai módszerre.

Bézier-görbe Egy Bézier-görbeszakaszt (azaz a spline egy-egy polinomját) négy pont ír le: ketten közülük (A és B pontok az ábrán) a szakasz két végpontját adják meg, amelyeken a fentieknek megfelelően a görbe feltétlenül átmegy, a másik két ún. vezérpont (C és D) a két végpont közötti görbeszakasz irányát és görbültségét határozza meg. A Bézier-görbeszakasz sosem lép ki a négy leíró pont által meghatározott konvex négyszögből. A görbevonal maga geometriailag könnyen meghatározható: az ábra szerint rajzoljuk meg az AC, CD és DB szakaszokat, majd ezek felezőpontjait kössük össze újabb szakaszokkal, majd az így kialakult öt kisebb szakasz felezőpontjait ismét kössük össze, és így tovább, a végtelenségig, amikor is megkapjuk a négy ponthoz tartozó Bézier-görbét. A görbét természetesen leírhatjuk képlettel is. Ha a t paraméter végigfut a 0 és 1 közötti értékeken, az alábbi összefüggések megadják a görbe x és y koordinátáinak értékeit:

x(t) = (1 - t)3 xA + 3t(t - 1)2 xC + 3t2(1 - t) xD + t3 xB
y(t) = (1 - t)3 yA + 3t(t - 1)2 yC + 3t2(1 - t) yD + t3 yB A gyakorlatban nem ezeket a képleteket szokás alkalmazni, hanem a deCasteljau nevéhez fűződő változatot, amely pár ekvivalens átalakítással, valamint a részeredmények elraktározásával és újrafelhasználásával körülbelül kétszeres kiszámítási sebességet tesz lehetővé. A t paramétert megfelelő lépésközzel léptetjük végig 0 és 1 között, és az így kapott x(t), y(t) pontokat egyenes szakaszokkal kötjük össze. A kapott vonal annál közelebb lesz az elméleti görbevonalhoz, minél kisebb az alkalmazott lépésköz, de annál több számolást is igényel. Mivel a PostScript nyelv magától értetődő része a valódi Bézier-görbék támogatása, a fontok (amelyek nem mások, mint szigorúan meghatározott szintaxisú PostScript programok) is ilyen módon írják le a betűk körvonalait. Ehhez 1000-szeres nagyítású koordináta-rendszert szoktak használni (de ez egyáltalán nem kötelező), szükség esetén tizedes törtek és negatív számok igénybevételével, az elméletileg lehetséges felbontás tehát igen nagy. A körvonalakat a True Type font egyenes vonalszakaszokkal és másodfokú B-spline görbeszakaszokkal írja le; az utóbbi is spline ugyan, de - másodfokú lévén - csak az első derivált folytonosságát tudja biztosítani: így csak kevésbé igényes körvonalleírásra alkalmas, mint a Bézier-görbék. Igaz ugyan, hogy kiszámításukhoz valamivel kevesebb idő szükséges, de ezt a nyereséget elveszítjük azzal, hogy a betűk íveit több kisebb szakaszra kell felvágnunk, hogy megfelelően leképezhessük alakjukat. Ráadásul még így is gyakran előfordul, hogy két egymás után következő ívszakasz megbicsaklással illeszkedik csak egymáshoz. Az egyes betűk körvonalát leíró pontsorozatok (a B-spline szakaszokat is két végpontjuk és két vezérpontjuk jellemzi) egy képzelt rács rácspontjaira illeszkednek. A rács sűrűsége a fontgyártó szándékától függ, de a True Type fontoknál a lehetséges legnagyobb értéke 32767×32767 rácspont lehet, amely elegendően nagy felbontást eredményez. A gyakorlatban a célzott felbontás és a betűtípus jellegzetességeitől függően ennél kisebb értékeket szokás alkalmazni.

Mi kell még egy fonthoz?

Körvonal raszterizálásaElső ránézésre úgy tűnhet, a körvonalak pontos leírása elegendő is egy betűtípus egzakt megadásához. Elméletileg ez így is van, de a gyakorlatban nem hagyhatjuk figyelmen kívül, hogy ezeket a betűképeket korlátozott felbontású eszközön (képernyő, nyomtató, levilágító) kell megjelenítenünk. Márpedig az ilyen készülékeken a görbe körvonalakat nem lehet közvetlenül megjeleníteni, csak a rendelkezésünkre álló képpontokkal tudjuk többé-kevésbé megközelíteni őket. Mint ahogy az az ábrán is látszik, a körvonal egyáltalán nem a pixelhatárokhoz igazodva húzódik, hanem közülük egyeseket kettévág. Ezeken a helyeken nem mindig egyszerű eldönteni, hogy a kérdéses pixelt bevonjuk-e a betű kialakításába vagy sem. Persze, ha a képelemek mérete kicsi (mondjuk, 2400 dpi vagy még nagyobb felbontás esetén), az ideális vonaltól való eltérés annyira kicsi lesz, hogy jószerivel el is hanyagolhatjuk. A ma még szokásos 600 dpi-s lézernyomtatás mellett (és még inkább az itt-ott még szolgálatban álló 300 dpi-s nyomtatóknál) azonban ezt már nem tehetjük meg: egy pixel ide vagy oda már észrevehető különbséget okoz. A képernyőn megjelenő betűk esetében, ahol a felbontás még egy nagyságrenddel kisebb, már komolyan oda kell figyelnünk, hogyan tudjuk a valódira legjobban emlékeztető betűformát megjeleníteni. Előfordulhat ugyanis, hogy a körvonal raszterizálása során például a H betű egyik szára egy pixellel szélesebbre sikerül, mint a másik, vagy a vízszintes és függőleges vonalak aránya nem megfelelő akár kerekítési hibák, akár az ideális körvonal és a pixelhatárok eltérő elhelyezkedése miatt. Szükségesnek tűnik tehát, hogy a körvonalakat megtámogassuk további információkkal is, amelyek segítenek a raszterizálónak eldönteni, hogy ilyen esetekben melyik pixelt jelöljék ki. Mindkét formátum tulajdonképpen program, amelynek végrehajtása során alakulnak ki a körvonalak. A méretezési segédinformációkat is ugyanezzel a koncepcióval kezelik, bár egyes hívők szeretik megkülönbözteni a kettőt: míg a Type 1 szokásos megnevezése hint (=tanács, útmutatás), addig a True Type elnevezéstana az instruction (=utasítás) mellett döntött. A végeredmény, persze, nem a néven múlik...

True Type instrukciók A True Type értelmezőprogramja alapesetben csak akkor jelöl ki egy pixelt, ha annak középpontja nem esik a kiszámolt körvonalon kívülre, így az instrukciók nélkül a betűk egyes részei eltűnhetnének vagy méretük megváltozhatna. Az instrukciókkal tehát meghatározhatjuk, hogy az interpreter milyen további szabályok szerint végezze a raszterizálást, például: a fenti esetben automatikusan módosítsa-e úgy a körvonal elhelyezkedését, hogy ne maradjanak le a fontos pixelek. Beállíthatjuk az értelmező által alkalmazott kerekítési algoritmust is, vagyis azt, hogy a körvonalakat a környezetében levő rácspontok közül melyikhez illessze. Ezen túlmenően lekérdezhetjük a korábbi kerekítések eredményét, hogy ezeket az adatokat felhasználva a betűk további részeinek arányát meghatározhassuk.

Zónák A megfelelő minőségű képalkotáshoz szükséges segédadatok a Type 1-nél más koncepcióra épülnek, mint a TrueType fontoknál. A Type 1 fontok nem hivatkoznak rácsra, hanem csak a betűk fontos elemeit és méretviszonyait írják le a hintek segítségével. Ezek egy része a font egészére határoz meg méretezési értékeket, mint azt az ábrán láthatjuk: a jelölt három ilyen zóna a kis- és nagybetűk magasságát, valamint az ívelt betűk esetén szokásos túllövést mutatja be. Ezek a méretadatok segítik a raszterizáló munkáját, amikor a matematikai eszközökkel számolt körvonal a jelölt zónák közelébe ér. További hasonló zónák jelölhetik az egyes fel- ill. lenyúló szárak elhelyezkedését, az ékezetek helyzetét. Más hintek az egyes betűkörvonalakhoz kapcsolódva, az adott betű fontos Hintek elemeinek méretviszonyait határozzák meg. Ez utóbbi hinteket leíró programrészleteket szubrutinokba is lehet szervezni, így az egy fonton belül ismétlődő részletek (például a szerifek) helytakarékosan és hatékonyan tárolhatók. Van még egy segédinformáció-fajta a Type 1 fontokban, de az nem szerepel minden fontban, csak ahol az egyenestől nagyon kevéssé eltérő, lapos ívekre van szükség, mint egyes betűtípusok ívelt szerifjeinél. Ezek a kis ívek alacsony felbontás esetén túl nagynak, torznak adódhatnak; a flex-nek nevezett járulékos információk ezen ívek megfelelő megrajzolásában nyújtanak segítséget. A True Type instrukciói a segédadatok szélesebb körét ölelik fel, mint a Type 1 hintjei. A két megközelítés közötti különbség elvi jellegű. A Type 1 nem a fontba, hanem a raszterizáló, értelmező programba építi be a megjelenítés tudományát, így a fontra magára kevesebb megoldandó részlet leírását bízza. A True Type ezzel szemben butább értelmezőt, de okosabb fontokat használ. Az előbbi megközelítésnek megvan az az előnye, hogy a raszterizáló továbbfejlesztésével a korábbi fontok módosítás nélkül tovább használhatók, és élvezik a jobb értelmezőprogram nyújtotta előnyöket. Mindkét formátumnak szüksége van az egyes betűk általános méretviszonyait, valamint az egalizálásra szoruló betűpárokat leíró adatokra is. Ezek a Type 1-nél külön fájlban foglalnak helyet, amelynek kiterjesztése .PFM vagy .AFM (a kettő gyakorlatilag ugyanazt az adathalmazt tárolja, a különbség csak abban van, hogy az .AFM egy olvasható ASCII fájl, amíg a .PFM bináris kódolású). A fontokat felhasználó rendszerek nem igénylik mindkettő meglétét, vagy az egyik, vagy a másik elegendő nekik. A True Type fontok a kétféle adatot egyetlen, tipikusan .TTF kiterjesztésű fájlban tárolják.

Mindez a gyakorlatban

A gyakorlati, tényleges összehasonlítást némileg bonyolulttá teszi az operációs rendszerek, programok és PostScript-nyomtatók, -levilágítók sokfélesége. Önmagában a fontformátumokat tekintve, a Type 1 fölénye a körvonalleírásban nyilvánvaló. A hintek és instrukciók összevetése nagyjából kiegyenlített képet mutat, bár a True Type-ban több az elvi lehetőség, a Type 1 szintén tudja mindazt, amire a gyakorlatban szükség van. Az igazi probléma akkor kezdődik, amikor a két formátum között konvertálni kell, márpedig ha olyan PostScript nyomtatóra, levilágítóra küldünk anyagot, amelyik nem érti konverzió nélkül a True Type fontokat, akkor a TTF-T1 átalakítást nem úszhatjuk meg. A betűkörvonalak konverziója aránylag tisztességesen le is zajlik; ne feledjük, a True Type-féle másodfokú B-spline részhalmaza a harmadfokú Bézier-görbéknek, tehát ebben az irányban - némi kisebb kerekítési hibáktól eltekintve - a konverzió nem jár komolyabb adatvesztéssel. A True Type rácsra alapozott instrukciói és a Type 1 zónaadatokra építő hintjei viszont egész koncepciójukban annyira eltérnek egymástól, hogy a Windows PostScript-nyomtatómeghajtója meg sem kísérli ezen adatok konverzióját. True Type font használatakor ilyen esetben tehát minden betűkialakítási segédinformáció elvész! Ilyen esetben tehát a True Type fontok nyomdai, minőségi munkára teljességgel alkalmatlanok. Ugyanez történik akkor is, ha nem közvetlenül nyomtatunk, hanem True Type fontok felhasználásával megalkotott grafikánkat PostScript fájllá (EPS-sé) konvertálva visszük át másik programba. Egyre több PostScript eszköz érti azonban már tolmács igénybevétele nélkül is a True Type fontokat (pontosabban, a Type 42 fontokat - ez nem más, mint a TTF font egy Type 1-szerű külső csomagolásban; természetesen a nyomtatómeghajtó feladata a TTF-ből Type 42-öt készíteni, ez azonban nem jár a tényleges adattartalom konverziójával, minőségromlás tehát ebben az esetben nincsen). A máshol már említett GhostScript is érti már ezeket a fontokat. Marad tehát a fontok kérdése - a True Type fontformátumban ugyanis potenciálisan jóval több van, mint amit a közkézen forgó betűkészletekben megfigyelhetünk. A True Type fontok 99 százaléka - még akkor is, ha neves fontgyártók nevét viselik - eredetileg Type 1 fontként látta meg a napvilágot, és onnan alakították át őket True Type-pá, ezzel jócskán rontva minőségükön (a konverzió ebben az irányban nem megy komoly veszteség nélkül, legalábbis automatikusan nem, jelentős kézi kiegészítő, javító munkát igényel). Alig pár éve született meg az első, natív True Type fontszerkesztőprogram, és csak akkor kezdtek el eredetileg is True Type-nak szánt fontokat készíteni, nagyon kevesek (leginkább a Bitstream, ők egyedül ajánlják minden fontjukat True Type-ként is, a többiek - Linotype, Monotype, Adobe - csak választékuk egy kis részét). A megfelelő minőségű True Type fontok elkészítése egyáltalán nem automatizálható, komoly programozói és tipográfiai felkészültséget, és nagyon sok kézi munkával járó tervezést igénylő feladat. Az így készült fontok már igazán nem rosszak, de aligha valószínű, hogy ilyenek százai, ezrei akadnának a kezünkbe, különösen nem a kézen-közön terjedő, gyengécske, amatőrszintű programokkal ide-odakonvertált fontok között. A végkövetkeztetés csak egy lehet: ha nem vagyunk biztosak abban, hogy a PostScript-eszközünk érti a Type 42 fontokat, hogy az általunk használt operációs rendszer, nyomtatómeghajtó és tördelőprogram képes ilyeneket mindenféle illetéktelen átalakítás nélkül előállítani, és nem tudjuk saját tapasztalatunkból vagy megbízható forrásból, hogy a True Type fontjaink az említett méregdrága, kiemelkedő minőségű változatból származnak, akkor mindenképpen óvakodjunk a True Type fontok használatától. A Windows 2000 előtti Windows-változatok nem ismerik fel maguktól a Type 1 fontokat (pontosabban az NT igen, de a képernyőre egy TTF-fé konvertált verziót használ, tehát nem lehetünk biztosak abban, hogy a papíron-filmen pontosan ugyanaz lesz, mint a képernyőn). Az Adobe Type Manager 4.1 Light változata azonban immár ingyenesen letölthető, semmi akadálya tehát, hogy bármelyik korábban szokásos Windows alatt is használhassunk Type 1 fontokat. Ez az ATM egyébként már az Open Type fontokat is ismeri, amelyekről amúgy is kell még pár szót ejtenünk...

Miben tud többet az Open Type?

1996-ban az Adobe és a Microsoft közös lépésre szánta el magát: összebékítve a kétféle fontformátumot, megalkották az Open Type-ot. A kettősség bizonyos értelemben megmaradt - egy közös, egyébként a True Type-ból származó külső csomagolás mögött egyaránt lehet True Type és PostScript font (ez utóbbi már nem teljesen Type 1, hanem annak tartalmilag továbbfejlesztett változata Type 2 illetve CFF néven, ráadásul a korábbinál kisebb méretet nyújtó, hatékonyabb tömörítéssel). A felhasználónak nem kell különösebben törődnie vele, melyik alváltozat található a fonton belül, a Windows 2000 és a további operációs rendszerek mindkettőt egyformán kezelik, bár az elnevezésben megmaradt a kettős konvenció: a True Type-tartalmú fontok tipikusan .TTF, a PostScript fontok .OTF kiterjesztést viselnek. A magától értetődő kényelmen - már hogy az operációs rendszer külön program nélkül, teljesen egységesen kezeli a kétféle formátumot - túl az Open Type jelentősen megújult belül is. Először is időben és elterjedésben, tehát gyakorlatilag teljesen együtt jár a Unicode kibővített karakterkészlettel. Bár technikailag a kettő független egymástól (lehetséges Unicode-os kiosztást használni korábbi TTF fontokkal, és Open Type-ot is Unicode nélkül), a DTP számára együtt jelentenek komoly előrelépést. Az új fontokba nem csak sok, eddig külön fájlban, külön név alatt szereplő betűt lehet összezsúfolni (például számos ékezetes betűt, vagy már írásrendszerek - cirill, görög és egyéb nem-latin ábécék betűit, szimbólumokat, matematikai jeleket, stb.), hanem tipográfiai változatokat is: ligatúrák, igazi kiskapitálisok, kurrens számjegyek, szókezdő vagy szóvégi betűváltozatok. A font tartalmazza az ilyen változatok és helyettesítő karakterképek pontos szerepét és előfordulási lehetőségeit, így a tördelőprogramok például automatikusan behelyettesíthetik a ligatúrákat a különálló karakterek helyére, vagy alternatív betűképet engedélyezhetnek egyes karakterek (például számjegyek, vagy többféle változatban előforduló szimbólumok) helyén. Mindezeket a szolgáltatásokat, persze, a tördelő- és grafikai programok tevékeny részvétele nélkül, csak az operációs rendszer önmagában nem tudja biztosítani - meg kell tehát várnunk kedvenc tördelőprogramunk olyan változatát, amelybe már ezt is beépítik. Az Adobe kezében levő InDesign ezen a területen kétségtelenül elhagyta versenytársait, bár számos más kérdésben csak mögöttük kullog. A Unicode és Open Type elsősorban az arab, kínai, japán és más hasonló írásrendszerek művelőinek hozott nagy megkönnyebbülést. A latin betűs tipográfia, ha némi kényelmetlenségek árán is (például különálló Expert fontok vagy a ligatúrák, karakterváltozatok kézi lecserélésre), azért nagyjából el tudta intézni igényeit az ANSI karakterkiosztáson belül, az ennél sokkal nagyobb változatosságot mutató ábécék azonban most először jutottak használható eszközhöz. Nem véletlen tehát, hogy az újonnan megjelenő Open Type fontok túlnyomó többsége ezen célterület igényeinek kielégítésére törekszik, és a sokezernyi klasszikus és modern latin betűtípus tipográfiai szempontokra is figyelő konverziója lassan halad. Kevés és viszonylag drága még a mi céljainknak megfelelő Open Type font a piacon, és alighanem évekbe telik még, amíg teljes egészében kihasználhatjuk majd előnyeit.

Hogyan telepítsek fontokat Windows 2000-re? Kell az ATM vagy nem?

Alapvetően nem, hiszen a Windows 2000-be már be van építve (nem csak az ATM-nek megfelelő tudás, hanem maguk az Adobe fejlesztette ATM-programfájlok; ez annyira így van, hogy ha mégis telepítünk egy önálló ATM-et, majd eltávolítjuk, ezzel ki is töröljük a szükséges fájlokat, és installálhatjuk újra a Windows-t). Két dolog van csak, amit ez a beépített Type 1 fontkezelő nem tud: a betűkészletek csoportokba rendezését és a Multiple Master fontok kezelését. Az előbbit viszont könnyedén elvégzi a Corel programok CD-jén is ott található, tehát ilyenformán ingyenes Bitstream Font Navigator, az utóbbi fontfajtáról pedig már az Adobe is lemondott, annyi gond volt vele. Egyébként volt rossz tapasztalat is a Win 2000-re telepített ATM-mel, ismerünk olyat, akinek teljesen tönkretette a fontkezelést (alighanem az eredetileg az operációs rendszerben levő és a később érkezett ATM-programrészek veszhettek össze), és csak a Win 2000 újratelepítésével tudott megszabadulni a bajoktól. A javaslat tehát az, hogy ha nem feltétlenül szükségesek az MM fontok, akkor inkább ne telepítsünk ATM-et Win 2000-re. A fontkezelés legjobb módja egyébként a következő: Készítsünk elő egy saját könyvtárat az összes betűkészletünknek (külön-külön a különféle formátumoknak, például \Fonts\TTF és \Fonts\T1. Az előbbibe másoljuk át a \WinNT\Fonts könyvtárban található összes .TTF fájlt (ez a könyvtár rejtett rendszerkönyvtár, előbb tehát engedélyeznünk kell megjelenítését a Control Panel|Folder Options|View-ban, vagy valami tisztességes fájlkezelőt kell használnunk (pl. Windows Commander). Type 1 fontjainkat is másoljuk bele az imént létrehozott könyvtárba (mind a .PFB, mind a .PFM fájlokat, nem szükséges az utóbbiaknak a régi módon alkönyvtárat nyitni). Nyissuk meg a Control Panel|Fonts mappát, és töröljünk ki minden fontot (lesznek, amelyeket a Windows nem enged, nyugodjunk bele). Ezekután fizikailag is töröljük ki a .TTF fájlokat a \WinNT\Fonts könyvtárból (megint lesz, amelyeket nem lehet, vagy törlés után pár másodperccel automatikusan úja feltűnnek - velük ne törődjünk). A Fonts mappa File|Install New Font parancsával keressük meg előbb a TTF, majd a T1 fontjainkat és telepítsük mindegyiket, de nagyon figyeljünk, hogy a dialógus alján található Copy fonts to Fonts folder opció ne legyen bekapcsolva. Később, ha különféle programokat telepítünk, időnként ellenőrizzük, nem kerültek-e új fontok a \WinNT\Fonts könyvtárba. Ha igen, és úgy döntünk, hogy szükségünk van ezekre a betűkészletekre, ismételjük meg velük a fenti procedúrát. Mindezek után - ha szükségünk van a korábbi ATM Deluxe-okból ismeretes, fontokat csoportokba rendezve, együtt kezelő programra - elindíthatjuk a Bitstream Font Navigatort és a továbbiakban vele intézhetjük a fontok telepítését és kezelését. Ha megelégszünk azzal, hogy minden font egyszerre él (és a Windows 2000-en, akárcsak korábban az NT-n, ennek semmilyen teljesítménybeli hátránya vagy korlátja nincsen, többezer font is lehet egyszerre felinstallálva a legcsekélyebb gond nélkül), akkor semmilyen további programra nincsen szükségünk.

Időnként igen sajátos fontnevekkel találkozhatni, de sejtem, hogy ismert, régi betűtípusok rejtőznek az álnevek mögött. Mi ennek az oka, és hogy tudhatnám meg az eredeti nevet?

Az ok jogi eredetű, mivel a betűtípusok grafikai részleteit (az ún. metszetet) nem lehet jogilag levédetni, a nevét viszont igen - így sok fontgyártó a név átalakításával igyekszik kivédeni a jogi természetű bonyodalmakat. Az alábbi táblázat a praxisunkban már előfordult neveket tartalmazza. Természetesen nincs garancia arra, hogy az álnéven futó betűkészlet a nevétől eltekintve, egyéb részleteiben teljesen megegyezik a klasszikus eredetivel, kétely esetén tehát járjunk utána a betűk minőségének. Eredeti anyag: http://www.tramontana.co.hu/ventura/dtp/font.html