Názory k článku Písma a jejich použití: formáty písem TrueType a OpenType
-
Díky, tomu říkám dobře udělaný přehledný, srozumitelný a praktický úvod do použití a vlastností písma. Takhle uceleně a přehledně jsem to snad ještě nikde neviděl. Těším se na další díly!
Už teď jsem se ale dozvěděl různé střípky, které jsem neznal nebo měl o nich jen mlhavou představu: použití fontů na webu nebo některé vlastnosti fontů. Např. o alternativách znaků podle jejich sousedů jsem si myslel, že je uměl jen TeX se svými "nativními" metrikami TFM. Ten na to šel teda jinak (levá, střední a pravá část znaku), což nevím, jak řeší OTF.
Test češtiny je také popsán nejlépe, co jsem kde viděl. Přidám k "ďolíčku" ještě testy: "ďábel" (kolize háčku a čárky) a "loďka" (nejkrutější test, z mé zkušenosti).
Rozlišitelnost a čitelnost (skupin) znaků je téma už od dob, kdy menu na obrazovce bylo často Helveticou, ve které položka "Utilities" vypadala jak čárový kód...
12. 9. 2024, 03:02 editováno autorem komentáře
-
Filip JirsákStříbrný podporovatelJenom doplním drobnost, že CSS počítalo s tím, že písma nainstalovaná na počítačích uživatelů jsou různá, takže při určování toho, které písmo se má použít, se uváděl seznam písem. Prohlížeč pak použil první písmo ze seznamu, které bylo v systému k dispozici. Navíc ještě existují klíčová slova pro patkové, bezpatkové a strojopisné písmo, za která prohlížeč dosadil nějaké odpovídající písmo dostupné na daném systému. Těmito univerzálními písmy se pak seznam v CSS obvykle zakončoval. Takže definice pak vypadala třeba takto:
font-family: Verdana, Arial, Helvetica, sans-serif
Na novějších Windows se použila Verdana, na starších Arial, na Applu Helvetica, a na nějakém exotickém systému, kde by nebylo nic z toho, by se použilo nějaké bezpatkové písmo.
S nástupem webových fontů je možné použít vždy písmo podle vlastního výběru, ale ani před nimi to nebyla úplná katastrofa.
Dneska se něco podobného dá použít pro zrychlení zobrazení stránky. Načtení webového fontu přeci jen chvilku trvá, takže je možné text nechat zobrazit nějakým písmem ze systému, a když se stáhne webové písmo, překreslí se text jím. Akorát je potřeba vybrat ze systému co nejpodobnější písmo, aby při překreslení pokud možno nedošlo ani k jinému zalomení řádků, natož přeskládání celých bloků.
-
Filip JirsákStříbrný podporovatel
Protože čeština nemá předpřítomný čas. Podstatou bylo to, že před tím, než se začaly používat webové fonty a používaly se jen systémové fonty, nebyl tvůrce webu odkázán na to, že musí trefit písmo, které mají nainstalované úplně všichni (taková písma dlouho nebyla, protože množiny základních písem v systémech Windows a MacOS byly disjunktní).
-
-
Filip JirsákStříbrný podporovatel
Zatímco chybějící kerning je okamžitě vidět
Před celou kapitolou o kerningu měl být spoiler alert. Pokud někomu vysvětlíte, co je kerning, bude tím už postižen do konce života a chyby v kerningu uvidí všude :-) -
Tak hrozné to zase není. Ostatně vidí je každý. Těm méně typografií postiženým to jen podvědomě přijde "hezčí" když je to správně. Vysvětlením to prostě jen zvědomíte. A to je první krok k tomu, aby člověk dělal věci dobře.
Ostatně všiml jste si ve filmech vpravo nahoře promítačských značek po každých cca dvaceti minutách? Nejdřív jedné a pak druhé? Bang!
-
Pokud jste nejakou dobu pracoval s nejakym systemem do hloubky ktery maji na ocich ostatni muze vas to podvedome trochu rusit protoze vite co to je a jak se to ma delat spravne. Protoze jste musel tyto detaily vnimat v ramci vyvojoveho nebo kontrolniho procesu.
Ja treba vidim u analogoveho videa timecode. Kdyz nekdo spatne prevede video trha mi to oci. Zel se to stava i u profesionalni konverze a tak to obcas vidite i v televizi.
Existovaly formaty kde se timecode nezaznamenaval oddelene ale napriklad (nikoliv jen) ve VBI nebo misto audiostop (coz zase slysite pokud nekdo radne nemazal pasky). Jenomze obcas to ujede tak ze vidite i vbi sekci vcetne artefaktu ktere jsou v podstate casove kody.12. 9. 2024, 13:51 editováno autorem komentáře
-
RaviseStříbrný podporovatel
Od té doby, co ty značky povýšily ze šumu na signál? Když chytnu tu první, zbytek filmu do střihu jako by ani neexistoval.
-
Filip JirsákStříbrný podporovatel
Bitwarden to dělá obdobně – písmena černě, číslice modře, symboly červeně. Navíc má při generování hesla volbu „nepoužívat zaměnitelné znaky“.
-
Ondřej CaletkaZlatý podporovatelKdyž ještě fungovala EET, měli prodejci povinnost uvádět na účtenkách kód PKP, pokud se jim nepodařilo získat kód FIK. Kód PKP byl tvořen dlouhým řetězcem v kódování base64 a vlastně jsem nechápal, jaký má smysl jeho povinný tisk na účtenky, když zároveň nebyl nikde požadavek na použití písma, které zřetelně rozlišuje I, l, 1, O, 0. Několikrát jsem se pokoušel PKP z účtenek opsat, ale nikdy se mi nepodařilo celý kód opsat bez chyb.
-
Filip JirsákStříbrný podporovatel
V prvním díle je to vysvětlené. Anglicismus „font“ může znamenat kde co (písmo, rodinu písma, soubor…), význam slova „písmo“ je naproti tomu poměrně jasný.
-
Hm, ne, já bych to přece jen označil jako amerikanismus. John Cleese
sice tvrdí, že "There is no such thing as US English", ale bohužel si pořád musím dávat pozor na slovníky aby mi nenabízely US spelling (třeba color vs colour). A jelikož vývoj písem v počítačích počítačů probíhal převážně v USA, tak mi přijde označení amerikanismus jako přiléhavější než anglicismus. -
Filip JirsákStříbrný podporovatel
To skládání znaků ale funguje opačně. V Unicode můžete napsat č jako háček a c, ale při vykreslování se to pak nahradí právě znakem č. Jen tak zobrazit háček a znak nejde – u většiny znaků by to vypadalo špatně, u některých kombinací by z toho vznikl nesmysl (v češtině třeba ď nebo í).
-
Unicode má přeci dva typy diakritických znamének: samostatná, kdyby někde chtěl použít znaménko jako znak, a kombinační, která se mají zobrazit nad předchozím znakem.
Příklad:
ř (0159), písmeno vcelku
rˇ(0072 02c7), špatně
ř (0072 030c), písmeno a kombinační háčekUmístění háčku sice není ideální, ale furt lepší než čtvereček, nebo písmeno z jiného systémového fontu. Takže bych čekal, že pokud ve fontu není ř, že ho ta vykreslovací knihovna nahradí kombinací. A vono ne.
Určitě jste si všiml na plakátech, letácích, v inzerátech, na webech, prostě kdekoliv, kde je použit nějaký ozdobný font, že v textu místy jako péro z gauče trčí arialové ě, š a podobně. A pokud nevšiml, teď si všímat budete. :-)
-
Filip JirsákStříbrný podporovatel
0072 030c se právě má správně vykreslit pomocí znaku 0159.
Použití písma bez českých znaků si samozřejmě všímám, některé autory webů jsem na to dokonce upozorňoval. Ale to je chyba toho, kdo to písmo použil. Není úkolem vykreslovací knihovny, aby se to nějak snažila zachránit. Navíc když chybí znaky se diakritickými znaménky, nikde není zaručeno, že tam budou ty znaky, ze kterých by se to mohlo poskládat. Prohlížeče dokonce v DevTools ukazují, kolik znaků z daného písma bylo použito a kolik jich bylo nahrazeno.
-
Tak či onak, nahrazovat by to nemělo - to je právě mechanismus, jak řešit problém chybějících znaků, ale musí se to udělat výhradně ručně.
Tedy: když chybí písmeno s háčkem, zkusím to složit, když to nejde (nebo to blbě vypadá), zvolím jiné. U nadpisů na letácích a podobně to je (v nouzi) možné.
Ostatně, pokud nemá písmo podporu potřebné abecedy, je lepší se mu vyhnout a najít si jiné, podporované. -
Filipovy Jirsákovi se zřejmě nedaří pochopit, co chcete říct. Tak to zkusím já.
Při úvaze, zda by se neexistující glif měl nahradit kombinací se možná uvažovalo tak, že když by se to povedlo, bylo by to horší. Protože by si toho necvičené oko nemuselo všimnout. A tak je lepší, když to více "křičí", alespoň to motivuje aby se ten glif doplnil.
Druhý důvod, který mě čistě spekulativně napadá je ten, že by se někam musela zavést tabulka vztahů, že ř (0159) je ř (0072 030c). Neznám tak dobře unicode formát, zda je tam nějaký prostor pro takováto kouzla.
Podobný problém spočívá v tom, že tu teď uvažujeme nad diakritikou. Ale co třeba asijská písma, která mají spoustu zajímavých věcí. Vymyslí se i ta nějaké podobné fallbacky? A šlo by to vlastně? Ligatura pro lám+alif, by se nahradila za lám a alif, což by bylo pravopisně chybné... (a to jsme ještě u obyčejných ligatur).Možná nebyla poptávka :-)
-
Filip JirsákStříbrný podporovatel
Já to chápu.
Spousta znaků se skládá z nějakého základního znaku a jednoho či více modifikátorů. Unicode s tím počítá, takže třeba „r s háčkem“ jde vyjádřit přesně takhle, jako znak „r“ doplněný „háčkem“ (což je modifikátor, není to v pravém smyslu samostatný znak, nemá třeba žádnou šířku). Ten princip se používá v Unicode pro spoustu různých věcí – třeba máte základní smajlík, ten můžete modifikátorem doplnit o to, zda jde o muže či ženu, a jinými modifikátory můžete určit barvu pleti. Ale zpět k latince – ve starších znakových sadách se tohle řešilo tak, že to „r s háčkem“ mělo samostatný znak. No a Unicode to z historických důvodů převzalo, takže v Unicode můžeme „ř“ napsat jako jeden znak nebo jako dva znaky „r s háčkem“.
Pak máme nějaké písmo, které jednotlivým znakům přiřazuje tvary – glyfy. Takže v tom písmu máme třeba glyf pro ř nebo-li r s háčkem – a pozor, je to pořád ten stejný glyf. V žádném případě se to nedělá tak, že by se zobrazil glyf pro „r“ a přes něj glyf pro „háček“ – takhle gylfy pro písmena s diakritikou nejde vytvořit, diakritiku musí usadit autor písma pro každý znak zvlášť. To písmo třeba ani nemusí mít glyf pro samotný háček – a pokud ho má, není to proto, aby se někam sám přilepoval, ale pro případy, kdy potřebujete ten háček zobrazit samostatně.
Nebo-li ve fontu je zabudován způsob, jak kombinaci „r s háčkem“ zobrazit jako glyf pro „ř“. No a P_V by chtěl opačný proces – když se při vykreslování písma narazí na znak, který nemá ve fontu odpovídající glyf, měla by ho vykreslovací knihovna zkusit vykreslit z jednotlivých částí. K tomu by byla nutná ta tabulka pro zpětný převod, o které píšete. Třeba pro „ř“ by to bylo poměrně jednoduché, protože ten vztah, že „r s háčkem“ se normalizuje jako „ř“, je definován přímo v Unicode. Jenže třeba pro „í“ by to už použitelné nebylo, protože „í“ je sice „i s čárkou“, ale pro vykreslení by bylo potřeba použít glyfy „i bez tečky“ a „čárka“. Trochu jiný problém by byl z českých písmen s „ď“, jak jsem psal výše.
No a jak píšete dál, tohle by řešilo problém jenom pro pár jazyků, které mají oproti západoevropské latince pár znaků s diakritikou navíc. Nebo-li bylo by to dost složité na implementaci, a přitom by to prakticky nikomu nepomohlo. A navíc – ty znaky s automaticky přilepeným diakritickým znaménkem by prostě vypadaly ošklivě, nebylo by to o moc lepší, než když se to nahradí znakem jiného podobného písma. Pokud jde o nějaká ozdobná písma, kde použití náhradního písma vidí každý, tam by to automatické doplnění vypadalo hrozně a stejně by to každý viděl. Takže nemá smysl to řešit. Prostě je to na tom, kdo dané písmo použije, aby si ověřil, že má všechny znaky, které potřebuje. Pokud někdo vyrobí plakát s nějakým ozdobným písmem a nechá to tak i s tím, že některé znaky jsou nahrazené úplně jiným písmem – pak by se dotyčný měl od jakékoli práce s grafikou držet hodně daleko a dobře mu tak, že to každý na první pohled uvidí, že je to špatně.
-
Takhle jsem pochopil, že to myslíte už ve svém minulém příspěvku. (Uff, nedošlo k nedorozumění.) Co ale nechápu, je, k čemu je to užitečné. Jinými slovy: kdyby Unicode vůbec nic neuměl o nějaké kombinaci "r" a "háček", jak by se to prakticky projevilo oproti dnešnímu stavu?
Jestli to totiž dobře chápu, tak vůbec nijak. Pokud font obsahuje glyph pro "ř", použije se. A pokud ho neobsahuje, žádná informace o té kombinaci se nepoužije - dá se tam prázdný čtvereček, znak z jiného písma apod. Takže ta informace o kombinaci se nepoužije ani v jednom případě, k čemu pak je?Něco jsem přehlédl?
-
Filip JirsákStříbrný podporovatel
To, že „ř“ je „r s háčkem“ podle mne není v Unicode kvůli zobrazování, ale je to spíš technická věc. Třeba když píšete na klávesnici, napíšete nejprve háček a pak ř – a zapsat se to dá pomocí těch dvou znaků, nebo se to dá normalizovat do znaku „ř“.
-
Filip JirsákStříbrný podporovatel
Unicode není kódování písma, ale znaků. A Unicode opravdu nemá nic společného s rozložením kláves, uváděl jsem to jen jako příklad, kdy se to dá použít. Také třeba při různých převodech (odstranění diakritiky, převod na velká či malá písmena).
Každopádně zařídit v OpenType písmu zobrazení „r s háčkem“ jako „ř“ je snadné – je to úplně stejný princip, jako když se „ff“ zobrazuje jako slitek. A je to věc, která je definovaná přímo ve fontu. Opačný způsob (když není k dispozici glyf pro „ř“, zobrazit „r s háčkem“, by musela implementovat vykreslovací knihovna. A jak už jsem psal – uplatnilo by se to v minimu případů, a to vykreslení by stejně bylo více či méně špatně. -
Ano, funguje to podobně jako ligatury. Ale podle mě by to měla implementovat, i když tam ta "ligatura" (ř) není, vždyť ta implementace zní: "hele, knihovno, nedělej vůbec nic (navíc)". Prostě zobrazí základní znak (r) a následně znak háčku (ten má nulovou šířku a kresbu vlevo od referenčního bodu). A pokud nebude dobře sedět? Vždyť je to náhradní řešení, tak si tam sazeč přidá ruční kerning.
Ohledně těch využití, co píšete v prvním odstavci, mi to přijde všechno jen teoretické. Nic z toho není nijak napojeno na Unicode. Vemte si třeba konfiguraci XKB, tam je vlastní databáze názvu znaků a nemá žádné napojení na Unicode.
-
Filip JirsákStříbrný podporovatel
hele, knihovno, nedělej vůbec nic (navíc)
Nikoli. Ta knihovna by nejprve musela zjistit, že „ř“ se dá zobrazit jako „r s háčkem“. Pro „í“ by musela mít informaci, že se dá zobrazit jako „i bez tečky s čárkou“ a pak zjišťovat, zda má font glyf pro „i bez tečky“ (a také tu čárku). Přičemž výsledek by vypadal prakticky vždy ošklivě. A to celé by se dělalo jenom kvůli pár jazykům a situaci, kdy nějaký hlupák použije pro text písmo, které neobsahuje potřebné znaky, a je mu to jedno. Přičemž jazyků, kde by to vyřešilo problémy všech chybějících znaků, je ještě méně – asi budou i jiné, než čeština a slovenština, ale není jich moc. Protože takové ß, ł nebo i ą už takhle nevyrobíte.A pokud nebude dobře sedět? Vždyť je to náhradní řešení, tak si tam sazeč přidá ruční kerning.
Nejde zdaleka jen o kerning. A pokud to řeší sazeč a to písmo opravdu potřebuje použít, tak si potřebné znaky dodělá. Pokud se k něčemu ta samotná diakritická znaménka mají použít, tak právě k tomu, aby z nich potřebný znak vytvořil grafik, ne aby je někam „náhodně“ umístila vykreslovací knihovna.Ohledně těch využití, co píšete v prvním odstavci, mi to přijde všechno jen teoretické. Nic z toho není nijak napojeno na Unicode.
Stejně tak nejsou na Unicode napojeny fonty. Unicode je prostě obecná znaková sada, která nepředepisuje, jakým způsobem ji můžete použít. Akorát se její autoři snažili dát ostatním do rukou nástroje, které by jim mohly být užitečné. A jedním z nástrojů, které se zdály být užitečné, je i to umět napsat třeba „r s háčkem“ tímto způsobem (tedy jako spojení dvou znaků), protože se tak s tímto znakem ve spoustě případů pracovalo dávno před vznikem Unicode (a dávno před vznikem počítačů). No a OpenType fonty to díky podpoře ligatur pak umí i dobře zobrazit a aplikace nemusí před zobrazením Unicode textu dělat jeho normalizaci. -
Pardon, ale tady nesouhlasím.
S tou klávesnicí apod. mluvím o tom, že můžeme teoretizovat nad přesným významem Unicode apod., ale nezměníme tím ten základní fakt, že se na definici klávesových map nepoužívá - viz XKB apod. Ani si to neumím představit, protože by jinak ta klávesnice fungovala jen s jedněmi locales.
Ohledně zobrazení mluvím o něčem jiném. Já mluvil o případu, kdy sazeč zjistí, že ve fontu nemá ř - objeví se mu tam prázdný obdélníček. A on na to zareaguje tím, že on, RUČNĚ, nahradí "ř" dvěma znaky: "r" a "háček" a stejně tak ručně přidá případně kerning. Od zobrazovací knihovny pak nechce vůbec nic jiného než aby nedělala nic zvláštního, jen vysázela znaky.
A zdůrazňuji to slovo "sazeč", ať si je jakkoli nepřesné. Zdůrazňuji ho proto, aby bylo jasné, že to není typograf. Nechce a nebude si kreslit vlastní znaky, řešit v jakém editoru otevírat nějaké OTF, a hlavně jak ho exportovat tak, aby tam jen přibyl jeden znak a jinak se žádným způsobem ten font nezměnil, včetně milionu novodobých vlastností fontů, o jejichž existenci ten sazeč nemá ani ponětí, a tak je nemůže zkontrolovat.
Jediné, co by mohlo být navíc, ale nikoliv pro zobrazovací knihovnu, by byla např. chytrá schránka, která to převede podle Unicode na "ř" při akci "copy to clipboard", aby text takto zkopírovaný v jiném okně byl už normálně. Ale to je až třešnička na dortu, vůbec není životně důležitá a hlavně se vůbec netýká zobrazovací knihovny.
-
Filip JirsákStříbrný podporovatel
XKB není jediný způsob, jak zacházet s klávesnicí.
A on na to zareaguje tím, že on, RUČNĚ, nahradí "ř" dvěma znaky: "r" a "háček" a stejně tak ručně přidá případně kerning.
Tohle ale sazeč dělat nebude. Např. proto, že by mu jenom kerning nepomohl, musel by řešit i vertikální umístění háčku. A musel by to dělat pro každý výskyt ř v textu. Pokud už bude potřebovat použít dané písmo, tak si do fontu to ř doplní.Navíc kdyby to udělal tak, jak popisujete, přestalo by mu tam fungovat třeba dělení slov, v elektronickém výstupu (PDF) by nefungovalo vyhledávání slov obsahujících ř. Zkrátka by to celé přineslo akorát spoustu problémů.
Nechce a nebude si kreslit vlastní znaky, řešit v jakém editoru otevírat nějaké OTF
Už vůbec ale nebude nebude řešit nějakou náhradu jednoho znaku jinými a jejich pozicování. -
To už je úplně mimo jakoukoliv praxi, kam se ta debata zvrhla.
Pořád jsem se nedozvěděl, na co konkrétně a prakticky se teď používá ta Unicode vlastnost, že umí nadefinovat znaky i jako kompozity (ne teoreticky možná v budoucnu, ale teď a prakticky).
Naopak jste začal tvrdit věci naprosto proti mojí mnohaleté zkušenosti a chytáte se za jakási slovíčka a formulace a sám neřeknete příklad žádný. Není XKB jediná možnost konfigurace klávesnice? Ano, není - a co má být z hlediska argumentu o Unicode? Máte teda příklad jiného popisu, kde se ten Unicode používá? Pokud ano, proč jste ho nenapsal? A pokud ne, tak co má ten výkřik (užitečného) znamenat??
Další věc proti praxi je s tím kompozitem a kerningem. Přeci nikdo netvrdí, že tak chci sázet sázet knihu v kvalitě TeXu. Ale různé tiskoviny se tak běžně tvoří, protože sazeč/grafik potřebuje mnoho různých zdobných a jiných fontů a často se mu stane, že v nich není čeština nebo není kompletní apod. A tvrdit, co má raději dělat a nedělat je dost... No, řekněme to tak: zkuste ne na internetu, ale do očí říct nějakému grafikovi, že to dělá celé špatně a kvůli těm dvěma znakům v nějakém ozdobném nadpise (nebo třeba dvaceti v několika nadpisech) si má zaplatit kurs tvorby fontů a na dva týdny se vrhnout do učení. A pak pokaždé si každý takový potřebný font přetvořit.
To je celé... Jak píšu na začátku: úplně mimo praxi. Až bych se nebál to nazvat hraběcími radami.
Jelikož jsem se nic praktického ani na pátý nebo šestý pokus nedozvěděl, počkám raději, co bude v dalších dílech seriálu.
-
Filip JirsákStříbrný podporovatel
Z toho, jak se to dnes používá, neplyne nic o tom, jak to v minulosti bylo plánováno.
Samotný znak diakritického znaménka se může hodit třeba při psaní na klávesnici, kdy nejprve napíšete diakritické znaménko a to se zobrazí; nebo se to hodí třeba v textech o jazyku nebo typografii. Když chcete jiné příklady. Ale klíčové podle mne bylo to, že se to v minulosti jako samostatný znak vyskytovalo, takže dávalo smysl takové znaky zařadit i do nově vytvářené univerzální znakové sady.
Ale různé tiskoviny se tak běžně tvoří, protože sazeč/grafik potřebuje mnoho různých zdobných a jiných fontů a často se mu stane, že v nich není čeština nebo není kompletní apod.
Opravdu se to běžně dělá? Každopádně současná implementace umožňuje to, co chcete – a když se místo chybějícího znaku zobrazí čtvereček, je mnohem snazší takový znak najít, než kdyby se místo něj zobrazovala nějaká uměla generovaná náhrada.Každopádně v debatě o standardních vykreslovacích knihovnách je to úplně jedno, protože sázecí programy nemohou používat standardní vykreslovací knihovny pro výpis celého textu, protože pak by nemohly řešit právě takové věci jako ruční kerning, měnit velikost mezislovních mezer apod.
si má zaplatit kurs tvorby fontů a na dva týdny se vrhnout do učení
Na to fakt nepotřebuje žádný dvoutýdenní kurz.Jak píšu na začátku: úplně mimo praxi.
Gratuluj k objevu. V době, kdy vznikalo Unicode, vskutku s Unicode ještě žádná praxe nebyla. Celé to byla jenom teorie, jak by se to asi mohlo používat. A vytvořit samostatné znaky pro diakritická znaménka se tenkrát zkrátka jevilo jako dobrý nápad (a řekl bych, že se zpětně ukázalo, že to opravdu smysl dává). -
IMHO je to pozůstatek po psacích strojích - tam opravdu napíšete háček (bez posunu válce/vozíku) a teprve poté písmeno. Čímž vznikají tři možnosti: samotný háček (dopsaná mezera),
r s háčkem
ař
(napsané klávesou s pětkou).
A každé to vypadá jinak.
Unicode vznikalo v dobách, kdy byly psací stroje (a dálnopisy...) ještě poměrně běžnou součástí života.
Dneska mládeži těžko vysvětlíte i CR+LF/LF+CR/CR/LF, protože vůbec nechápou, proč tolik možností pro prosté ukončení odstavce (řádky se přeci zalamují samy). -
Byly tu nějaké dotazy a komentáře ohledně Unicodu, takže zkusím něco málo napsat. Unicode vznikl v roce 1991 na základě spolupráce lidí z Xeroxu, Applu, Microsoftu, NeXTu, Sunu, a dalších co se přidali po cestě. Očekávalo se, že bude popisovat pouze moderní písma, a počítalo se s 16-bitovými znaky. Je to přece triviální: 65535 znaků, protože "to musí stačit každému", a prvních 256 z důvodu kompatibility kopírovalo ISO 8859-1. Trochu problém vznikl s CJK ideogramy, tj. čínskými, japonskými a korejskými znaky. Ty totiž existují v tradiční a zjednodušené formě. Pevninská čína používá zjednodušené znaky. Japonsko, Hong Kong, Taiwan, Singapur, a k tomu občasní a historičtí uživatelé Filipíny, Jižní Korea a Vietnam používají tradiční znaky, s tím že si je ale v některých případech také různě zjednodušili. Jenže mít každý znak několikrát by nešlo, nevešlo by se to. Takže pánové usoudili, že v Unicode bude každý znak jen jednou, protože mají oba stejný význam, a prezentace konkrétní formy toho znaku bude čistě věcí fontu. Zajímavé je, že na rozdíl od CJK symbolů jsou v Unicode písmena A a А, O a О a Ο apod., které sice mají stejný význam, ale jsou z latinky, azbuky, a (v druhém příkladu) řečtiny. Pravidlo o jednom znaku pro jeden význam zjevně platí pouze pro CJK symboly. Dále přidali například full-width latinku a čísla, které se používají při psaní CJK ideogramy, pokud chcete mít "západní" znaky stejně široké jako CJK ideogramy.
Pokud jde o implementaci, tak opět platí "je to jednoduché". Windows NT používají od začátku 16-bitový wchar_t; co wchar to znak, co znak to pozice ve fontu, znak se vykreslí na obrazovce nebo tiskárně... K Unicode-enabled API mají paralelně API v 8-bitové "ANSI" kódové stránce systému, a ta se interně převádí na Unicode. Unicode verze každého API končí na W, ANSI verze na A, například CreateFileW a CreateFileA. Zní to skvěle, je to jednoduché, ale počkejte si na dějový zvrat.Na Unixech to bylo složitější, protože v průběhu a po Unix Wars neexistovala autorita, která by řídila vývoj API unixových systémů. Nakonec došlo k přidání velmi omezené podpory locale pro wchar, který byl obyčejně (ale zřejmě ne vždy) 32-bitový. Nikomu se ale nechtělo předělávat všechna API používající 8-bitové chary na 16- nebo 32-bitové wchary, mimo jiné protože je na to navázaná spousta datových struktur, a navíc to neměl kdo koordinovat napříč Unixy. Naštěstí kdosi přišel s myšlenkou, jak Unicode protlačit skrz API stavěné na 8-bitové chary. Pro tento účel vznikla kódování UTF-1, UTF-7 a UTF-8; to poslední jistě znáte. V principu se 16-bitové Unicode wchary přeloží na sekvenci 8-bitových charů. V případě UTF-8 to navíc má kompatibilitu s ASCII (dolních 7 bitů), a pokud je nastavený osmý bit, tak jde o součást sekvence, takže je možná resynchronizace pokud začnete číst uprostřed streamu. UTF-8 se po pár letech rozšířilo. Trochu problém nastal v tom, že se v každém API mohl míchat text v "tradičních" kódových stránkách s textem v UTF-8, podle toho jestli aplikace používala nebo nepoužívala Unicode, a to například u názvů souborů nebylo úplně ideální. Podobně když aplikace zavolala X11lib s požadavkem "vykresli tento string", tak nebylo jasné, jestli je v UTF-8 nebo v ISO 8859-x. Navíc aplikace používající Unicode většinou používaly (a používají) stringy založené na wcharu. Unixy měly prostě horší technické řešení ve srovnání se systémy založenými na wcharech, což jsou Windows NT, .NET, Java, Qt, NextStep a OS X (Cocoa API). Tedy vyjma toho, že u wcharu je problém s endianness. Když nevíte, v jakém kódování Unicode text je, tak se dá použít Byte Order Mark, který je na začátku stringu... Je velmi často nepodporovaný a způsobuje problémy, takže se moc nepoužívá (na Unixech, co vím, jen raritně). Navíc endianness znamená průšvih pro portabilitu datových struktur... To není vše, na dějový zvrat dojde záhy.
V roce 1996 vyšel Unicode 2.0. Při jeho vývoji bylo zjevné, že je projekt úspěšný, a také že se všechny znaky do 16-bitové tabulky nevejdou. Proto vymysleli vyjma UTF-1, UTF-7 a UTF-8 také UTF-16 pro reprezentaci více než 65536 znaků. To znamená, že pak ani u systémů s 16-bitovým wcharem neplatí, že jeden wchar je jeden znak. K tomu přišly kompozitní znaky, řekněme r plus ˇ, a tabulka toho, které kombinace odpovídají předdefinovanému znaku (zde ř). K tomu Unicode (již z dřívějška) obsahuje řídící znaky, které například u arabských znaků indikují, jestli se mají spojit "na čáru", nebo jestli mají zůstat oddělené. Když se znaky spojí "na čáru", tak dostanou jinou formu, což často vyžaduje další "znaky" - glyphy - ve fontu. Je to další odklon od konceptu jeden wchar je jeden znak. A podobně jako na Unixech s UTF-8 je i na NT/.NETu/Javě/Qt/OS X možné mít text s neplatnými UTF-16 sekvencemi, které sice prolezou skrz většinou API, ale nedávají smysl. Implementace Unicode (a OpenType, který je do věci logicky zapojený) je výrazně složitější, než na začátku cesty. S víceznakovými sekvencemi, ligaturami, podporou jazyků psaných zprava doleva, hromadami modifikátorů atd. bych už řadu let rozhodně nepsal "je to jednoduché". A Microsoft minimálně pro multiplatformní vývoj her doporučuje používat "ANSI" API s 8-bitovými znaky, přepnuté do UTF-8.
Co se stalo od doby Unicodu 2.0? Nic moc. Unicode přidal podporu dalších živých i mrtvých jazyků, včetně klínového písma a egyptských hieroglyfů. K tomu další CJK symboly, symboly měn atd. Vyjma pár odborníků to nikoho nezajímá. Výjimkou je přidávání nových emoji, kombinačních znaků pro určení barvy pokožky u emoji, kombinační znaky typu "žena plus dítě", "muž plus vozík" apod. To je v podstatě jediná věc, o které se u nových verzí Unicode mluví. Poslední verze má 154 998 znaků, a dá se čekat, že ještě pár desítek emoji bude přidáno :)
Ještě zpátky k těm kombinačním znakům. Jak jsem psal, znak ř je možné alternativně zapsat jako r plus ˇ. Proto ISO 10646 (což není úplně totéž co Unicode) popisuje různé normalizace textu: NFD (Normalization Form Canonical Decomposition, ř se převede na r plus ˇ), NFC (Normalization Form Canonical Composition, r plus ˇ se převede na ř pokud lze), NFKD (Normalization Form Compatibility Decomposition) a NFKC (Normalization Form Compatibility Composition). Ty normalizace nejsou bijekce, tj. nutně neplatí že vstup převedený z NFC do NFD a zpátky bude shodný s původním. Compabitility (de)composition řeší věci typu převodu římského čísla xii na znaky xii, ligatura ffi se převede na znaky ffi, index ⁵ se převede na 5 atd., což je dobré například při hledání v textu; dále nebudeme řešit. Windows by default používají NFC, takže jména souborů jsou ve formě "ř", pokud to lze (a pokud někdo nedonutil Windows to udělat jinak). OS X používá NFD, takže například jména souborů jsou ve formě "r plus ˇ". Pokud je o Linux, tak nevím, ale například u Samby se řešilo, jestli "ř" a "r plus ˇ" v názvu souboru je totéž, a údajně to způsobovalo i ztrátu dat (nevím jak). Opět "je to jednoduché" neplatí, ani název souboru už není jen string charů nebo wcharů, a je třeba nad tím přemýšlet.
Další kategorií komplikací je třeba možnost změnit směr psaní textu, což může vyústit v bezpečnostní problémy - text na pohled vypadá jinak, než co obsahuje (a v případě skriptu/kódu dělá). Ještě bych přidal již delší dobu profláknuté případy, kdy si někdo nechal vystavit certifikát například na jméno Microsoft, ale jedno z písmen "o" bylo z azbuky, což vizuálně nepoznáte. Protože nešlo o Microsoft zapsaný plně v latince, tak certifikační autorita prostě vystavila certifikát, nejspíš automaticky. Skvělý způsob jak podepsat malware platným a zdánlivě důvěryhodným certifikátem, ale dneska to už neprojde.
Kdo to dočetl až sem, ten je extrémní geek. Komu by to nebylo zjevné: to je označení pochvalné, svým způsobem prestižní.
