Rozumíme si s fonty - kódování - Grafika.cz - vše o počítačové grafice

14. září 2000, 00.00 | Snad každý, kdo pracuje pravidelně s počítačem, se již setkal s problémy, souvisejícími s používáním textu. Jaká jsou potenciální úzká místa?

Snad každý, kdo pracuje pravidelně s počítačem, se již setkal s problémy, souvisejícími s používáním textu. Někdy jsou vyvolány kódováním textu, někdy použitým fontem. Nevyhýbají se nikomu, ani uživatelům v anglicky mluvících zemích. Potenciálních úzkých míst v počítačových systémech je více, a my je budeme v několika souvisejících článcích postupně odkrývat.

Začneme kódováním znaků, které zejména tuzemským uživatelům připravuje občas horké chvilky. Přitom jde o úlohu, která je v principu poměrně jednoduchá. Jen je třeba se smířit s tím, že na praktické úrovni se musíme vyrovnávat s mnoha nedokonalostmi. Neseme si je s sebou jako důsledek historického vývoje a protože často požadujeme zpětnou kompatibilitu, nemůžeme se jich zatím beze zbytku zbavit. Nejde přitom zdaleka jen o problém s jazyky zemí bývalého východního bloku, i když dlouhodobá mezinárodní izolace situaci ještě zhoršila. Značné problémy jsou ale i třeba s jazyky národů Blízkého východu, Japonska nebo Číny.

Kódování, fonty - jak to spolu souvisí

Je třeba si hned na počátku uvědomit, že kódování znaků je jedna samostatná úloha, a konstrukce fontů a jejich používání je věc druhá, na kódových tabulkách nezávislá. Znakové sady ovlivňují uložení textových informací (řetězců, stringů) v počítači a způsoby práce s nimi. Počet znaků ve znakové sadě je obvykle omezen, systémy neumí (či neuměly) adresovat příliš mnoho prvků najednou. Je to podobné, jako s barvami na monitoru - je jich jen tolik, kolik si může uživatel dovolit paměti.
Znaky samotné ale uživatel nezobrazuje ani netiskne. To, co vidíme, jsou tvary, které znaky navenek graficky zastupují. A soubor tvarů, to je font. Měl by být vytvořen s ohledem na konkrétní jazykovou mutaci znakové sady, ale technicky vzato, tvarování fontu není na znakové sadě nijak závislé.
Posledním faktorem, který vstupuje do hry, je ovladač klávesice (trochu zjednodušujeme, těmto mechanismům se budeme podrobněji věnovat v dalších článcích). Kódová stránka, ovladač klávesnice a aktuální font jsou navzájem propojeny - mechanismus spolupráce se ale v jednotlivých operačních systémech liší.

Jak může být vytvoření vhodného kódování složité? Nejčastěji jsou dnes používány tabulky, které obsahují vždy 256 znaků. Pro většinu hlavních světových jazyků lze zkonstruovat tabulku, která je ve 256 znacích pokryje. Neexistuje už ale 256-ti znaková tabulka, která by dokázala sama najednou pokrýt výraznou většinu hlavních jazyků, dokonce není možné jednou takovou tabulkou pokrýt ani jazyky národů, sdružených v Evropské unii. Kromě toho existuje více jazyků, které se v současnosti stávají pro počítačový průmysl stále významnějšími a obsahují řádově více znaků. Sady Tradiční Čínská, nebo Japonská a další, vyžadují průměrně 12 až 16 tisíc znaků.

Jak to vše začalo

Kolébkou počítačové techniky (jen té moderní, praktické) jsou anglicky mluvící země. Prakticky ale hovoříme jen o USA, které si od počátku získaly a udržovaly ve vývoji a hlavně v praktické aplikaci počítačů výrazný náskok. Jistá sebestřednost Američanů je dobře známa, a tak se není co divit, že se textová komunikace mezi počítači omezila jen na americkou angličtinu. A ještě jeden faktor tu hrál výraznou roli: úsporné mechanismy. Dobře si pamatujeme, že před půl rokem očekával celý svět příchod roku 2000. Kdysi dávno ušetřili vývojáři trochu tehdy drahocenného místa v paměti, a zakódovali datum jen z části. A to šlo jen o trošku místa, v porovnání s tím, kolik paměti zabere zakódování znakové tabulky.

Co to je kódová tabulka? Pokud jde o pojmy, u jednoduchých tabulek s 256 znaky se v podstatě stírá rozdíl mezi tím, když mluvíme o kódové tabulce a kódové stránce. Opatrnější bychom měli být u novějších řešení, třeba znaková sada (znaková tabulka) WGL4 pokrývá hned několik kódových stránek.
Máme-li vysvětlit sám princip znakových tabulek, dovolíme si nejprve malou odbočku. Počítač (digitální, zde je to třeba dodat) umí pracovat jen se dvěma logickými hodnotami, nulou a jedničkou. V informatice používáme jednotku, nazvanou jeden bit, a ta může nabývat právě jen těchto dvou hodnot, jedna a nula.
Pro počítání v nulách a jedničkách se hodí jiné soustavy, než desítková - používáme dvojkovou a šestnáctkovou soustavu, řídce osmičkovou. Není to moc složité, jen místo mocnin desítek pracujeme s mocninami dvojek a šestnáctek. Do nul a jedniček převádíme vše, tedy i znaky, udáváme v nich adresy v paměťovém a diskovém prostoru počítače. Podle toho, kolik různých informací potřebujeme odlišit, musíme použít více, nebo méně bitů. Tak například šestici jedniček či nul (tedy šest bitů), můžeme kombinovat celkem 64 způsoby, a proto může šest bitů zaznamenat (vyjádřit, uložit) celkem 64 různých informací, třeba znaků, nebo popsat 64 míst v paměti (říkáme tomu adresovat).

A jsme zpátky u znakových tabulek. Každý znak musí mít své číslo, se kterým bude počítač pracovat. Znaky a jejich čísla jsou uspořádány do tabulky, kterou musí mít k dispozici všichni, kdo si potřebují vzájemně předávat své dokumenty. To nebyla vždy až taková samozřejmost, v dřevních dobách počítačů se prakticky nikdo na kódovací standardy neohlížel, slušně pokryto bylo jen několik západních jazyků a zbytek se musel řešit jen případ od případu, jako speciální zákaznické provedení systému.

ASCII a ti ostatní

Za první široce rozšířený standard je jistě možné označit základní ASCII tabulku. Ta byla sestavena z celkem 128 znaků. Znaky jsou proto vyjádřeny čísly od 0 do 127, resp. v šestnáctkové soustavě od 00 do 7F. A proč právě 128 znaků? Protože pro jejich vyjádření je třeba jen 7 bitů, což stačí na velká a malá písmena anglické abecedy (latinky), "diakritiku" americké angličtiny, deset číslic a nějaké ty řídící znaky. Nezapomínejme, že osmý bit není jen tak nějaká jednička či nula, jeho přidáním bychom velikost zabraného místa (z logiky dvojkové soustavy) rozšířili rovnou o dalších 128 pozic.
Základní ("pravá") ASCII tabulka je dodnes živým a užitečným nástrojem. Oněch 128 znaků je se svými kódy obsaženo ve všech ostatních kódovacích systémech, včetně nejnovějšího standardu Unicode. V současné, mnohdy nepřehledné situaci, dává použití prostého ASCII jistotu, že při přenosu dokumentu nedojde k záměnám nebo ztrátám znaků v textu (nebo v názvu souboru).

Logickým dalším krokem jsou tzv. OEM kódové stránky. Slůvko OEM proto, že každý výrobce si mohl vytvořit své vlastní kódování. I když se tento termín dnes příliš nepoužívá, přece OEM tabulky důvěrně známe - patří sem všechna běžná tradiční kódování češtiny.
Asi nejsilnějším impulsem ke vzniku původních rozšířených tabulek byla snaha rozšířit chudé grafické možnosti tehdejších počítačů. Semigrafické znaky, jako jsou linky, čtverečky, rámečky a další, problém elegantně řešily, jen pro ně bylo potřeba další místo. V OEM tabulkách se takové našlo, a to rovnou dalších 128 pozic, s čísly od 128 do 255, resp. v šestnáctkové soustavě od 80 do FF.

Opět si tu dovolíme malé odbočení. Jak vidíme, samotné označení ASCII tu již není na místě, to bychom pro 256-ti znakové tabulky používat neměli. Rovnou bude dobré osvětlit i druhé malé nedorozumění, vycházející z ustáleného označování obou polovin rozšířených tabulek. Podle toho, jak za sebou následují adresy v tabulce, mluvíme o ASCII polovině jako o spodních 128 znacích, zatímco o polovině, obsahující semigrafiku, jako o horních 128 znacích. Protože jsou ale tabulky v manuálech vždy tištěny s nulou v levém horním rohu, nedivme se, že horní polovinu tabulky nacházíme až dole.

Jak se brzy ukázalo, OEM kódové stránky se výborně hodily i pro umístění národních znaků - přirozeně na úkor semigrafiky. Tak postupně vzniklo množství tabulek, typicky rozlišených třímístným číslem podle vzoru CP XXX. A tady přichází ten okamžik "zmatení jazyků" - OEM kódové stránky vznikaly bez velkého ohlížení na normy a standardy. Proto se dodnes potýkáme s tím, že pro jeden jazyk může existovat několik různých kódových tabulek, které se v umístění znaků národní abecedy liší. A není to jen případ češtiny, i když bychom možná mohli aspirovat na jedno z prvních míst, co se počtu používaných kódování týče; ostatně posuďte sami. Poznamenejme, že s mnohými z nich se stále rozloučit nemůžeme, zejména z důvodů zpětné kompatibility. Jak hned uvidíme, stejná situace se navíc opakuje i u modernějších kódovacích systémů - všechny hlavní aplikace jich musí podporovat hned několik.

Kódování bratří Kamenických

Toto kódování je používáno na počítačích IBM kompatibilních a je označováno i jako CP895. Velmi známý je řídící program klávesnice KEYBCS2, jehož autory byli právě bratři Kameničtí. Toto kódování bylo na PC pod DOSem donedávna dokonce nejoblíbenějším kódováním, neboť zachovává veškeré grafické znaky; rovněž mnoho tiskáren umí takto kódované texty vytisknout.

Kódování KOI-8 ČS2

V dobách RVHP jsme se často řídili normami KOI, zmíněné kódování je jedním z takových případů. V souladu s českou abecedou obsahuje zvláštní znaky pro velké a malé "ch" a většinu českých znaků s diakritikou lze získat pouhým nastavením osmého bitu. Kódování bylo používáno na starých terminálech a v současné době již není aktivně využíváno (s výjimkou některých programů, jako 602Text).

CP852

Kódování CP852 je určeno pro PC a je označováno i jako IBM852, PC Latin 2 nebo PC L2. V dokumentaci k MS DOS je PC852 nazývána jako "Slavic (Latin II)", přestože kromě slovanských jazyků pokrývá i potřeby jiných jazyků, např. maďarštiny. CP852 je podporováno většinou současných programů pro DOS a OS/2. IBM a Microsoft ho definovali jako kódovou stránku CP852 a i ČSN 369103 jeho používání pro PC doporučuje. U nás je známo jako Latin 2, ale nesmíme ho zaměňovat s ISO Latin 2, neboť obě kódování se výrazně liší.

East8

České kódování East8 používala u svých zařízení kdysi firma HP.

ICL

Zde jsou české znaky umístěny na pozice řeckých písmen a ze známějších programů ICL kódování používal textový editor CSED. Dnes se již toto kódování nepoužívá.

ISO-8859-2

První, které bychom mohli zařadit mezi moderní, živá kódování. Mezinárodní standard ISO-8859-2, známý také pod názvem ISO Latin 2, je shodný se stránkou IBM912. Podle norem by asi mělo být ISO-8859-2 jediným všeobecně používaným kódováním češtiny. Ale vzhledem k historicky utvářené situaci na poli kódování češtiny a vlivu Windows tomu tak není. Norma ISO-8859-2, specifikující ISO Latin 2, je jednou z norem řady 8859-X a pochází z roku 1987. Norma doporučuje ISO Latin 2 používat pro albánštinu, angličtinu, češtinu, maďarštinu, němčinu, polštinu, rumunštinu, slovenštinu, slovinštinu a další jazyky. ISO Latin 2 podporuje snad každá významnější aplikace, včetně těch z produkce Microsoftu (zejména kvůli kompatibilitě na Internetu).

Windows 1250

Toto kódování je označováno i jako CP1250, WinCS nebo WinEE. Opět jde ve skutečnosti o celý komplex kódových stránek, Windows ANSI, kde jsou horní poloviny znakových tabulek vyhrazeny pro národní abecedy (například Win 1252 obsahuje znaky pro západní Evropu, 1253 pro řeckou abecedu). Windows 1250 obsahuje všechny tisknutelné znaky sady ISO-8859-2. Hlavním rozdílem je, že čtrnáct znaků s diakritickými znaménky (z toho osm pro češtinu a slovenštinu) má na jiných pozicích. Vzhledem k masovému rozšíření operačního systému Windows jsou zmíněné kódové stránky prakticky standardem.

Mac OS Central European

A nesmíme zapomenout ani na počítače Apple. Česká kódová tabulka systému Mac OS se ode všech popsaných liší. Stejně podstatně se ale liší i sama práce systému se znakovými sadami, jak uvidíme v dalších pokračováních seriálu o fontech. Kódování češtiny na Apple je označováno i jako MacCE, Apple-ce atd. Je vhodné upozornit, že písma s koncovkou CE pro Mac nelze zaměňovat s písmy s koncovkou CE pod Windows. Kódování pro Mac OS je velmi mladé, protože vznikalo až na popud a pod dohledem firmy Apple před uvedením těchto počítačů na trh. Struktura kódování je přizpůsobena firemním standardům, podle kterých se lokalizované operační systémy Mac OS vytvářejí.

Když 256 znaků nestačí

Znakové sady, které jsme doposud probírali, se obecně označují jako SBCS (Single Byte Character Set), každý znak je vyjádřen jedním bytem (a tedy 8 bity). Klasické tabulky už ale dnes nestačí, a to zejména ze dvou důvodů. Za prvé, jak už víme, pro řadu zejména asijských jazyků je 256 znaků zoufale málo. Ale ani práce s evropskými sadami není jednoduchá. Tabulka sice pokryje jeden jazyk, ale v situaci, kdy do anglického textu potřebujeme vložit třeba řecké znaky, se přepínání fontů nevyhneme.
Potřebujeme-li adresovat (používat) v daném okamžiku více znaků, znamená to, že potřebujeme vícebytovou znakovou sadu. Všichni tuší, že skončíme u Unicode, což je striktně dvoubytová sada, ale to až za chvilku.

Než se dostaneme k UNICODE, pozastavíme se u vícebytových znakových sad. Neznamená to snad, že by takové sady využívaly pro zakódování znaků více, než dva byty. Jde o to, že nejsou ani jednobytové (SBCS), ani dvoubytové (DBCS); obsahují znaky vyjádřené oběma způsoby. Nese to s sebou spoustu programátorské práce, protože počítače se musí v textu orientovat. Jednoduše řečeno - musí poznat, jestli ještě čtou druhý byte znaku, nebo již první byte znaku následujícího.

WGL4 character set

Mnozí uživatelé Windows se při čtení předcházejích řádků jistě trochu podivili. Jejich systém přece pracuje s fonty, které obsahují daleko více znaků. Je to díky rozšířené evropské (PanEuropean) znakové sadě WGL4.
WGL4 je blízko k Unicode, protože využívá schopnosti operačních systémů Windows (od 95 výše) znaky podle tohoto standardu adresovat. Na rozdíl od Unicode ale nejde o čistý DBCS, protože některé znaky jsou adresovány jen jedním bytem. WGL4 je společná tabulka znaků pro západní, střední a východní Evropu, spolu s řeckými a tureckými znaky. Jinými slovy, pro dříve samostatné kódové stránky 1250, 1251, 1252, 1253 a 1254 potřebuje u WGL4 uživatel jen jednu společnou znakovou sadu o celkem 652 znacích, rovněž fonty pro WGL4 obsahují tvary pro všech 652 znaků. Při práci měníme jen národní sadu ("klávesnici"), ale font zůstává stále tentýž. Informace o pokrytých kódových stránkách jsou operačnímu systému k dispozici přímo v těle fontu - podle toho se rozhodne, ke kterým stránkám bude mít uživatel při práci s fontem přístup. Proto u WGL4 fontů pro Windows zmizelo ono "CE", a přesto píší česky. Jedinou vadou tohoto jinak celkem pohodlného nápadu je, že ne za všech situací a ne ve všech aplikacích funguje bezchybně. Jak jsme řekli, implementovat vícebytová kódování je poměrně složitá záležitost, a je otázkou, zda vývojáři již neobracejí své síly spíše směrem k Unicode.

Unicode Consorcium

Jak jsme již naznačili výše, vedla snaha o vyřešení problémů s omezeným prostorem vymezeným původním OEM tabulkám v roce 1991 k oficiálnímu založení Unicode Consorcia. Cílem Consorcia bylo spojit síly významných průmyslových společností a vývojářů k vytvoření 16-bitového kódování (čistého DBCS systému) pro znaky všech nejdůležitějších světových jazyků. Původní cíle, které vedly k návrhu Unicode Standardu, byly tyto:

• univerzálnost - kapacita znakové sady musí být dostatečná k zahrnutí všech znaků, které by mohly být použity při výměně textů, zejména znaků zahrnutých v hlavních mezinárodních, národních a průmyslových znakových sadách;
• jednoznačnost - kterákoli hodnota musí reprezentovat v různých kontextech stejný znak tak, aby dokumenty mohly být interpretovány vždy stejně;
• jednoduchost - konstantní šířka znaků dovoluje efektivní třídění, hledání, zobrazování a editaci textů. Text složený z posloupnosti znaků o konstantní šířce (bez přídavných řídících znaků) je velmi jednoduchý na zpracování. Software nemusí dávat pozor na speciální řídící sekvence a není nucen prohledávat text dopředu nebo dozadu kvůli identifikaci znaků.

Mezi určité nevýhody 16-bitového kódování patří:

• větší délka textu - text v šestnáctibitovém kódování znaků má dvojnásobnou délku než v osmibitovém kódování, což ovlivňuje požadovanou kapacitu na přenos a uložení informací, zdánlivě bez přidání informační hodnoty, a z důvodu většího objemu je i zpracování textů pomalejší než u jednobytového kódování.
• 256x větší znaková sada - znaková sada v Unicode obsahuje 256x více znaků než pro osmibitové sady. Nároky na paměťový prostor, zejména pro uložení fontů, jsou tudíž mnohonásobně větší. Vzhledem k tomu, že v mnoha národních sadách se používá jen nepatrný zlomek z celkového množství znaků, v praxi reálné soubory fontů Unicode obsahují pouze znaky pro dané národní prostředí, a v případě potřeby je možno pořídit fonty s plnou znakovou sadou.
• nekompatibilita s osmibitovým prostředím - Unicode text může legálně obsahovat znaky, které se v osmibitovém textu nemohou běžně vyskytovat, nebo tyto znaky mají v osmibitovém prostředí speciální význam.

Unicode - lék na všechny problémy

Standard Unicode navržený Unicode Consorciem představuje dvoubytové kódovací schéma s neměnnou šířkou, které je určeno pro zápis textu a umožňuje adresaci 65 536 míst, tj. svou kapacitou pokrývá potřeby všech znaků mezinárodní znakové sady.
Standard Unicode definuje numerickou hodnotu a jednoznačný název pro každý ze znaků mezinárodní znakové sady a dále obsahuje mimo tabulky kódů a názvů jednotlivých znaků i další informace, které jsou nezbytné pro implementaci kódování, ale obvykle ve znakových sadách chybí.

Ukázka dvoubytového kódování standardu Unicode:

V současnosti standard Unicode ve verzi 3.0 obsahuje 49 194 znaků světových abeced. Jazyky, které v současnosti kódování Unicode pokrývá, jsou například ruština, arabština, anglosaština, řečtina, hebrejština, Thai a Sanskrit a další. Dále obsahuje znaky sjednocené podmnožiny Han, která obsahuje 20 902 grafických symbolů definovaných jako národní a průmyslové standardy Číny, Japonska, Koreje a Taiwanu. Standard Unicode navíc zahrnuje matematické operátory a technické symboly (například některé geometrické tvary) a několik grafických symbolů.

A jak v denní praxi

Ačkoliv výše uvedené zásady a postupy se zdají být jednoduché a logické, v praktickém životě se přesto setkáváme s celou řadou problémů. Pokusme si je alespoň zhruba roztřídit. Pokud jde o chyby při přenosu dokumentů v češtině, vidíme dva hlavní zdroje potíží. Prvním je používání starších počítačů a aplikací, druhou pak nutnost udržovat a pracovat se staršími dokumenty. Setkáme se i s kódováním, pro jehož použití již moderní programy namají prostředky. Pak se může stát, že přenos lokalizovaných dokumentů selže. Zejména to platí, pokud nejde o prostý text, ale o nativní dokumenty (layout programy, tabulkové kalkulátory, kanelářské a speciální aplikace). Zde platí, že až nyní, při použití moderního software, je problém kompatibility prakticky vyřešen, a to i při meziplatformním přenosu PC - Mac. Do budoucna by se již ani nepoučení uživatelé neměli setkávat s velkými potížemi.

Úplně jiné problémy přináší používání aplikací, které jednoduše nejsou pro multijazyková prostředí uzpůsobeny. Takové programy jsou stavěny pro práci pouze s anglickou abecedou, a tak jejich tvůrci předpokládali, že program pro svoji práci potřebuje znaky pouze v rozsahu do 127 a vyšší kódová čísla může ignorovat. Jak jsme si ukázali dříve, spadají české znaky s diakritikou do ignorované oblasti a nemohou být tudíž těmito programy zpracovány. Jedná se většinou o grafické programy, které původně měly práci s písmem pouze jako doplněk bez jakéhokoli požadavku na kvalitu služby. Například program Adobe Acrobat je schopen zobrazit soubor s českým textem, ale vnitřně znaky nad 127 nahrazuje mezerou, takže při pokusu o práci s českým textem, jako jsou například funkce najdi a nahraď, nefunguje korektně. V těchto případech však bude čeština snad těžit z vlivu ohromných asijských odbytových teritorií, neboť právě z důvodu uplatnění výrobců programů na těchto teritoriích se prosazuje používání standardu Unicode. Mnohé programy již nyní vnitřně s tímto standardem pracují a další výrobci u nových verzí programů ohlašují schopnosti, které naznačují, že se ke standardu Unicode také připojují. Příkladem může být ohlašovaná "japonská" verze programu Adobe Acrobat, která již pracuje se znaky od pozice 128 výše a je tak schopna plnohodnotně pracovat i s českým textem.

Specifickým zdrojem problémů je práce s dokumenty, pocházejícími z exotických jazykových prostředí. U tuzemských firem zaznamenáváme v poslední době zvýšený zájem klientů o zpracování dokumentů v ruštině a jazycích dalších okolních zemí. S využitím stávajících programových prostředků jsou tyto úlohy poměrně obtížně řešitelné a vyžadují značné znalosti. Řešením budou opět aplikace pracující s Unicode. Tady mají v současnosti mírný náskok uživatelé počítačů na platformě Wintel, kde je podpora Unicode širší. Markantně je to vidět na příkladu textového editoru Word. Ve verzi pro Windows nejsou například s ruštinou problémy (díky podpoře Unicode), na rozdíl od verze Wordu pro Mac OS, která na implementaci Unicode stále čeká.

Problémy mohou způsobovat i samotné fonty, které byly dříve v některých případech špatně lokalizovány. Mezi základní problémy, na které můžeme narazit při použití českých fontů, patří:

• v souboru fontu je nesprávně vyplněná hlavička. Font obsahuje hlavičku, kde jsou uvedeny údaje pro práci programu, jako například identifikační číslo znakové sady. Pokud je identifikační číslo vyplněné nesprávně, neumí některé programy pracovat s českou sadou znaků;
• ve vnitřní tabulce jmen znaků je uvedeno nesprávné jméno pro upravený znak. Jednotlivé znaky jsou v rámci fontu adresovány podle tabulky jmen znaků, kde je k číslu znaku přiřazeno jméno, označující vlastní znak uvnitř fontu. Jména jednotlivých znaků jsou normována a každý znak má přiřazeno své nezaměnitelné jméno, které ve všech fontech označuje stejný znak. Problém nastane, pokud při počešťování fontu byl pouze upraven tvar znaku na dané pozici a byl uložen pod původním jménem znaku, tj. nebylo mu přiřazeno nové správné jméno. Tato chyba vznikala zejména zpočátku, kdy lokalizátoři fontů neměli dostatek zkušeností a používali programové vybavení, které například dovolovalo změnu tvaru znaku, ale neumožňovalo změnit jiné informace obsažené ve fontu. V době vzniku takto lokalizovaných písem tento nedostatek příliš nevadil, některé nové programy však neumějí s takto špatně lokalizovanými písmy pracovat (např. Adobe InDesign). Tento problém by však již neměl být příliš aktuální. Fonty od renomovaných českých i zahraničních výrobců lokalizované v poslední době pracují korektně, a lokalizátoři původních fontů nabízejí často jejich bezplatnou výměnu.

Používání národních znakových sad je, jak jsme se přesvědčili výše, poměrně složitá otázka, a pokud nejsou pečlivě dodržována daná pravidla, může docházet ke značným problémům s přenositelností a zpracováním informací. Systémová a široká podpora standardu Unicode je do budoucna zřejmě jedinou možností, jak se mezinárodně a s konečnou platností vypořádat s tlakem na celosvětové sdílení dokumentů. Pokrok a zlepšení ale rozhodně nepřijde příliš rychle. Za implementací Unicode je nutno vidět velké množství nejen normativní, ale především programátorské práce. S trochou fantazie ale budoucí výsledek - již nikdy špatně zobrazený či vytištěný znak - rozhodně za námahu stojí.

Připravili Rostislav Kareš a Kamil Třešňák

Článek byl převzat z měsíčníku Svět tisku.