Ciężki los cyfrowej typografii w erze wektorowych dinozaurów

IBM PC wykorzystywał standard ASCII. To dobrze, bo alternatywą był głównie standard EBCDIC, czyli coś doprawdy potwornego. Jednak ASCII jest zabawnym standardem do wykorzystania w pecetach, bo został zaprojektowany dla telegrafów. Jeżeli perspektywa przeszczepu obcej technologii nie budzi zatem wystarczająco silnego niepokoju sama z siebie, śmiem nadmienić, że oryginalny standard ASCII jest siedmiobitowy. Siedem bitów pozwala na zapisanie 128 stanów, czyli (naturalnie) połowy tego, co da się pomieścić w jednym bajcie. Mamy zatem do czynienia z kompletnie postrzelonym kompromisem: jeden bajt to za dużo, żeby trzymać alfabet, ale za mało, żeby trzymać coś więcej.

[img=029-card]

Pierwsze 32 stany bajtu to sekwencje sterujące (poza powrotem karetki są tam przydatniejsze rzeczy, jak symbol końca pliku), zakres do 127 to symbole drukowalne, a nadwyżka w postaci ósmego bitu dawała swobodę zagospodarowania. W ten sposób powstało koszmarne zjawisko o nazwie „strony kodowe”. Strona kodowa opisywała, jak wykorzystać dodatkowe stany. Domyślna strona kodowa 437 (tak wysoka liczba powinna tu dawać do myślenia) była dla Polaków całkowicie bezużyteczna – co prawda pozwalała zapisać moją ulubioną literę „duże a z kółkiem” (A), ale wszelkie swojskie ogonki były jej obce. W tym celu trzeba było używać strony kodowej IBM 852, która łaskawie obsługiwała polskie znaki, oraz całą górę innych śmieci. Kodowanie IBM 852, znane także jako IBM Latin-2, było jednak zupełnie różne od kodowania ISO Latin-2, bardziej znanego pod nazwą ISO 8859-2 i będącego przy okazji Polską Normą (PN-93/T-42118, ostatnio zaktualizowana w roku 2003!). Tę drugą nazwę powinni kojarzyć wspomniani na początku internauci, ponieważ na przełomie wieków konieczne było ręczne przestawianie przeglądarek internetowych na kodowanie 8859-2 po tym, gdy jakaś zagraniczna strona WWW „kradła” ustawienie i automatyczny wybór, dokonywany przez Internet Explorera, serwował tekst ujęty w kodowaniu „Europa Zachodnia (ISO)”. Każdy, kto kiedykolwiek walczył z literką „ł” wyświetlaną jako trójka w górnym indeksie, wie o czym mówię. Rzecz jasna, Windows stosował domyślnie jeszcze inne kodowanie znaków (CP-1250). Kto o tym nie wiedział, szybko był katapultowany z IRC-a.

[img=Screenshot(17)]

Wyżej opisane perypetie oznaczają, że wraz z dokumentem tekstowym konieczne było załączanie informacji o użytej stronie kodowej. Gdy automatyczne wykrywanie zawiodło, tekst wyjściowy wyglądał denerwująco nieczytelnie. Rozwiązanie tego problemu jest proste, ale tylko z naszej dzisiejszej perspektywy. Wiele czynników złożyło się na fakt, że nie zastosowano od razu jedynej słusznej metody zapisu znaków: UTF. Standard UTF, czy ogólniej – Unicode, polega w skrócie na wykorzystaniu więcej, niż jednego bajtu dla jednego symbolu. Szczegóły techniczne standardu Unicode są szalenie interesujące i opisują implementację takich cudownych wynalazków, jak modyfikatory glifów (pozwalające na dodanie konkretnego rodzaju akcentu do symbolu). Unicode nie jest „stroną kodową”: nałożenie stron kodowych na tekst UTF-8 poskutkuje wyjściem pełnym śmieci i robaczków, bo bajty sterujące symbolem będą nieprawidłowo przypisywane rzekomym literom, podczas gdy w praktyce są czymś zupełnie innym.

Dodanie pomocniczego bajtu do zapisu znaków wzbudziło oczywiście sprzeciw, ponieważ wszystkie pliki tekstowe w efekcie dwukrotnie „puchły”, a dyski twarde nie są z gumy. Ponadto, pojawiły się problemy ze zgodnością w systemach, które z niemal chorobliwą namiętnością stosowały bezwarunkowo jednobajtowe kodowanie. Kłopoty zaczynają się tak naprawdę bardzo wcześnie: chociażby trawersowanie łańcuchów tekstowych. Początkujących programistów C i gromadę zagubionych studentów, przyuczanych na pierwszych zajęciach do stosowania C++, łączy wspólny los podczas stosowania zmiennej typu ‘char’ do skakania po stringu. Wszak „oczywistym jest, że” sizeof(char) = 1. Ta informacja zamyka nowicjuszy w potrzasku pewnej konwencji, z której wielu z nich nigdy nie ucieka, a jedynie oddala problem od siebie, przechodząc na wyższe języki, jak Java czy .NET, które ukrywają tego typu dylematy przed światem. Dlatego z tak szaloną odrazą podchodzę do tych wszystkich „Hello World” w postaci czarnych, konsolowych okienek wyświetlających przez cout hasło „Witaj, ¦wiecie!”. Z powodu owych pierwszych lekcji, obsługa polskich znaków uchodzi u wielu za rocket science, a taki typ, jak wchar_t – za zbędne komplikowanie sobie życia.

[img=xxd]

Doskonały artykuł wprowadzający do tematyki Unicode napisał Joel Spolsky. Wypełnia on dokładnie te braki, które posiadają osoby nieobeznane z tematem i nie popada w nadmierną encyklopedyczną szczegółowość, jak wiele otępiających artykułów na Wikipedii. Chciałem swego czasu wysłać podziękowanie za ten artykuł, ponieważ używałem go jako pomoc naukową, ale okazało się, że autor jest szefem portalu Stack Overflow, co oznacza, że musiałbym mu podziękować za znacznie więcej…

Ale odeszliśmy od meritum. Unicode być może sprawia problemy, niektóre z nich są nawet całkiem zabawne (jak endianness– kierunkowość przetwarzania danych, oznaczana kodem EE FE), ale docelowo rozwiązuje on więcej problemów, niż tworzy, będąc rozwiązaniem przyszłościowym. Na co dzień nie używamy badziewnych mikrokontrolerków z 4KB pamięci, programowanych w niskopoziomowym dialekcie ANSI C, a całkiem mocnych komputerów ogólnego przeznaczenia, które możemy wykorzystać na wiele innych sposobów, niż tylko utrudnianie sobie życia. Wiedział o tym Microsoft, projektując system „NT OS/2 3.0”. Dzięki czemu obecne Windowsy stosują wewnętrznie kodowanie Unicode, w przeciwieństwie do Windowsów klasycznych, dawno wymarłych, zafiksowanych na jednobajtowych stronach kodowych. Dzięki temu obsługa obcych języków, wraz z szalonymi akcentami i oddzielnymi alfabetami, jest prostsza (czytaj: w ogóle możliwa).

[img=droppedImage_2]

Unicode jest „odporny na przyszłość”, ale skala jego rozbudowania jest tak duża, że jest odporny również na przeszłość, nadmiar kreatywności i cały ogrom solidnie idiotycznych pomysłów. Na pytanie „ile znaków jest w stanie zakodować Unicode?” odpowiedź „wszystkie” wcale nie jest aż tak abstrakcyjnym dowcipem. Obecnie zakodowano nieco ponad 100 tysięcy znaków. Jeżeli wydaje się, że to mało, pragnę przypomnieć, że nasz alfabet ma tylko 32 litery. Więc są to bez mała trzy tysiące naszych alfabetów. UTF-8 potrafi pomieścić milion znaków (z lekką górką), więc możliwe jest zakodowanie nie tylko wszystkich obecnie używanych języków, ale także wszystkich kiedykolwiek używanych. Dlatego już teraz zaalokowano wszystkie znane symbole każdego rodzaju cyrylicy, włączając w to symbole zregionalizowane, wymarłe, wycofane oraz ozdobne, jak np. moje ulubione „mnogo-oczne O”, występujące tylko w jednym miejscu jednego psalmu, którego zapis znajduje się w zbiorze monasteru Świętej Trójcy Ławry Troicko-Siergiejewskiej w obwodzie moskiewskim (opisywał on objawienie „wieloocznych serfaniów”). Bez problemu zmieści się tam również cały zbiór wszystkich opisanych znaków przepięknego, nieodszyfrowanego pisma rongorongo. Tym bardziej pomieściłby się para-alfabet manuskryptu Wojnicza.

[img=rongorongo003]

Wraz ze wzrostem popularności i eliminacją alternatywnych kodowań, Unicode w nieunikniony sposób dobrnął do etapu, na którym nie służy już tylko do ułatwienia wymiany dokumentów czy archiwizacji dowolnego pisma, zapisanego w dowolny sposób. Było tylko kwestią czasu, gdy UTF dostąpi zaszczytu kontaktu z kulturą, która zaoferowała nam takie osiągnięcia jak Hello Kitty, pojedynki na świetlówki, absurdalną pornografię i teleturniej „Śliskie Schody”. Mowa rzecz jasna o Japonii, która na przełomie wieków była źródłem kreatywnego wykorzystania tzw. przestrzeni zagospodarowania prywatnego w standardzie Unicode. Firma NTT DoCoMo, w okolicach roku 2000 stosowała w swoim komórkowym komunikatorze pozaalfabetyczne piktogramy, zawierające symbole dla warunków atmosferycznych, znaków zodiaku i tym podobnych. Dekadę później, rozszerzony i unowocześniony zbiór takich symboli został skodyfikowany i włączony jako podzbiór wersji 7.0 standardy Unicode. Rozpoczęła się era emoji.

To dobry moment na skorygowanie pewnego poglądu, że emoji to oddzielna czcionka. Jest to bowiem nieprawda, wynikająca z przypisywania symbolom emoji roli porównywalnej z nieszczęsną czcionką „Wingdings”, dołączoną do systemu Windows 3.0. Zawiera ona zestaw tzw. dingbatów drukarskich oraz całkiem sporo kompletnego, mało wyszukanego śmiecia. Jest to jednak zwyczajna, wektorowa czcionka typu TrueType, będąca na równi z innymi, jak np. Times New Roman. Wielki czarny kwadrat nie jest oddzielnym symbolem, a jedynie literką „n”, zapisaną w… niecodziennym kroju. Wymyślenie czcionki Wingdings było doraźnym rozwiązaniem problemu braku symboli drukarskich w czasach, gdy komputery PC stawały się coraz popularniejsze w branży DTP. Obecnie wielki czarny kwadrat nie musi być zapisywany jako litera „n” w czcionce Wingdings, ponieważ dostał on, wraz z całą gamą drukarskich bibelocików, własny symbol Unicode. Jest nim U+2B1B BLACK LARGE SQUARE. Oznacza to, że jest „literą”, na prawach prawdziwego alfabetu. Tak samo sprawa ma się z emoji. Są one glifami przewidzianymi w pliku czcionki jako symbole na prawach innych znaków – nie są fikuśną czcionką do zapisu normalnego alfabetu.

Nie oznacza to oczywiście, że każda czcionka musi koniecznie implementować znaki o indeksach rozpiętych na wysokich wartościach, przeznaczonych dla emoji. Niemal żadna czcionka tego nie robi. Co więcej – niemało czcionek domyślnie instalowanych w systemach operacyjnych nie zawiera nawet polskich znaków narodowych! Dlatego silniki składania tekstu stosują awaryjną ścieżką krytyczną („fallback”). Poniższy wycinek powinien być bliski twórcom stron WWW, jest bowiem typowy dla arkuszy CSS:[frame]p { font-family: "Times New Roman", Times, serif; }[/frame]

Nakazuje on użycie czcionki „Times New Roman” (TrueType’owego pliku z fontem o takiej ściśle nazwie), w przypadku jej braku – dowolnej czcionki z klasycznej rodziny „Times”, a gdy one również są nieobecne (cóż wobec tego wyświetla tę stronę!? Toster?), pierwszej dostępnej czcionki szeryfowej. W podobny sposób zachowują się edytory tekstu i programy graficzne – dlatego tak często na niechlujnie przygotowanych grafikach (a czasem nawet na oficjalnych materiałach promocyjnych!), polskie znaki wyglądają nieco inaczej niż reszta tekstu. O ile błędnie dobrany kerningjest dla mnie zjawiskiem zasmucającym, acz powszechnym, to polskie ogonki w rażąco odmiennym od otoczenia kroju wywołują u mnie stany lękowe i napady nieukierunkowanego gniewu.

[img=ogonki]

Ponieważ awaryjna ścieżka krytyczna nie dotyczy tylko całych czcionek, ale i pojedynczych znaków, w przypadku emoji następuje fallbackdo specjalnie przygotowanej czcionki zawierającej symbole przewidziane dla nich w Unicode. Taka czcionka zazwyczaj jest w systemie jedna, najwyżej o kilku krojach. Wszystkie pozostałe, w przypadku próby zapisania emoji, będą wskazywać właśnie na nią i przy okazji stronić od zaimplementowania własnych symboli, żeby fallback działał poprawnie. W systemie macOS taką czcionką jest Apple Color Emoji TTF. Windows używa zbioru Segoe UI Emoji, rozszerzonego o aktualizację 2729094 (zintegrowaną z Windows 8). Nowe wersje Unicode, wprowadzające nowe symbole Emoji, wymagają aktualizacji dedykowanej dla nich czcionki w systemie.

Rozwój wielobajtowych systemów zapisu tekstu, standard Unicode oraz popularyzacja Emoji jednoznacznie prowadziły do kluczowego, przełomowego momentu w rozwoju typografii cyfrowej, jakim było stworzenie emoji z dinozaurem. Na tę chwilę z niecierpliwością czekały miliony ludzi na całym świecie, od lat głośno i wyraźnie artykułując swoje pilne potrzeby. W ostatnim kwartale roku 2016, Komitet Techniczny Konsorcjum Unicode zaaprobował (między innymi) dwa symbole: U+1F995 ‘SAUROPOD’ oraz U+1F996 ‘T-REX’. Najnowsza wersja systemu Windows 10 (1709) zawiera czcionkę implementującą wyżej wymienione dinozaury: uogólnioną sylwetkę gadziomiednicznego zauropoda oraz ikonę wielkiego tyranozaura królewskiego. Od tej chwili nic już nie jest takie samo.

[img=sauropod_1f995]

Najważniejsze środowiska pracy oraz strony internetowe dostarczyły już swoje implementacje owych emoji. Apple, Google, Microsoft oraz WhatsApp, Facebook i Twitter mają już swoje dinozaury. Niestety, poprawne odzwierciedlenie cech składających się na zauropody pozostawia nieco do życzenia. Przede wszystkim, większość implementacji emoji U+1F995 wpada w pułapkę konwencji, jaką jest mylne zakładanie, że zauropod koniecznie musi być z rodziny Macronaria i należy go przedstawiać jako pewną wariację na temat brachiozaura (Giraffatitan). Prawdopodobnie ze względu na charakterystyczny kształt czaszki. Jest to jednak zdecydowanie zbyt zawężona perspektywa, nieuwzględniająca różnorodności podgatunkowej, co (jak mniemam) jest zapewne źródłem całkiem zasadnego oburzenia. Poprawnie uogólnione sylwetki zauropodów dostarczają czcionki autorstwa Microsoftu i Twittera, choć tutaj napotykamy inne wątpliwości. Wciąż nierozwiane są wątpliwości dotyczące koloru brontozaurów i brachiozaurów, dominujące hipotezy są naturalnie oparte o potencjalną zdolność do kamuflażu. Poprzedni pogląd, porównujący prawdopodobny kolor zauropodów do koloru słoni i nosorożców, powoli przegrywa z hipotezą lokującą kolor raczej w charakterystyce bliższej żyrafom, co szło w parze ze zmianą nazwy rodzajowej. Niestety, tego typu dywagacje nie zostały nawet podjęte przez większość graczy na rynku Emoji i zdecydowano się na stereotypowo „gadzi”, acz prawdopodobnie zupełnie chybiony, kolor zielony. Ponownie chlubnym wyjątkiem pozostaje tutaj Microsoft.

Bardzo dobrze broni się też dinozaur drukarski, czyli emoji bez nałożonego koloru. Aczkolwiek, został zaimplementowany wyłącznie w zbiorze Segoe UI, w przeciwieństwie np. do ośmiornicy, która ma swój ekwiwalent w bezszeryfowej czcionce Consolas o stałej szerokości. Trudno jednak nie oprzeć się wrażeniu, że ośmiornica w wydaniu monospace wygląda, jakby nie czuła się najlepiej…

[img=notepad]

Absurdalna dygresja paleontologiczna była okrężną metodą zwrócenia uwagi na kwestię „drukarską”, z perspektywy składu i publikacji tekstu. Pierwszy raz zetknąłem się z nim około 2 miesiące temu (w przeciwnym razie naprawdę nie zajmowałbym się dinozaurami!), gdy wracałem kolejny raz przeczytać/posłać komuś artykuł z Niebezpiecznika z roku 2012. Zawiera on łańcuch tekstu „ö˘<de=¦IEEEMlsqlexec¦9.280 RDS#R000000¦sqli ˘3˘¦ nmap¦nmapol=tlitcp˘h”. Czytałem ten artykuł trzy razy na przestrzeni pięciu lat i za każdym razem wyglądał inaczej. Za pierwszym razem, pik oraz uśmiechnięta buźka wyświetlały się jako kwadraciki (missing character). Potem już były widoczne normalnie, ale w wersji, jak na wydruku: czarno-białe („ö˘<de…”). Natomiast dzisiaj, co wygląda szczególnie zabawne w połączeniu z terminalową czcionką Monospace, wyświetlają się jako żywe, kolorowe symbole, z rumieńcami.

To bardzo niedobrze. Musimy o tym porozmawiać.

Czcionki emoji przechodzą przez ten sam cykl, co kiedyś gry komputerowe, a następnie interfejsy użytkownika, mianowicie pogoń za szczegółami. Gry dobrnęły do etapu, na którym wyglądają hiperrealistycznie, ale jakimś cudem często są beznadziejne. W międzyczasie swoją popularność zbudowały setki rozpikselowanych gier, jak FEZ. Udowadniają tym samym, że to „gameplay” jest istotny, a grafika jest tylko środkiem wyrazu. Gry na Atari 2600 wymagały od wyobraźni o wiele więcej, niż miejscami najnowszy „Wiedźmin”. Teraz, obciążenie zostało przełożone z wyobraźni na moc obliczeniową karty graficznej. Podobnie z interfejsami użytkownika: Windows Vista był najpiękniej opracowanym graficznie Windowsem, wiele jego cech wizualnych widać dalej w wiekowym już dziś Windows 7. OS X, ze swoimi wektorowymi i/lub hiperrealistycznymi ikonami i tłami również stawiał poprzeczkę bardzo wysoko. Każdy kolejny system aspirował do tego, by wyglądać lepiej, niż poprzednik pokazując tym samym, że potrafi zmusić sprzęt do bardziej imponujących efektów. Tyle, że to zupełnie niepotrzebne. Dziś już wiemy, że komputer osobisty, a nawet telefon, potrafią wyświetlić nie takie cuda. Żadne UI nie musi nam tego udowadniać. Środowisko pracy ma być przede wszystkim łatwo nawigowalne i nie wchodzić w drogę. Takie podejście, acz w dość ekstremalny i nie do końca przemyślany sposób, wprowadził Windows 8 i jest ono stosowane do tej pory. Interfejs użytkownika, tam gdzie jest to możliwe, jest renderowany z wykorzystaniem akceleracji 3D. Ale ze swej natury jest bardzo prosty. Najnowsze wersje Windows 10 dodają nieco animacji, ale są to jedynie subtelne kontury kreślone światłem, widoczne głównie podczas obsługi środowiska z użyciem myszy, a nie palców.

[img=Windows_Vista_Flip_3D]

Czcionki emoji jeszcze do tego nie dorosły. Chcąc wyglądać jak świeże, nowe, wyróżniające się rozwiązanie, przeszkadzają w nieplanowanych miejscach i obniżają czytelność, w praktyce prowadząc do spadku, a nie wzrostu wykorzystania w niektórych scenariuszach. Nie jestem wrogiem emoji, choć często są rozwiązaniem sztucznie stworzonych problemów (jak limit znaków na Twitterze). Istnieje jednak zbiór scenariuszy, w których są przydatne, zwłaszcza w czasach powszechnie coraz mocniej szwankującej zdolności koncentracji. Ale koniecznie trzeba coś zrobić z ich czytelnością, zanim zaczną wszystkich denerwować. Dokładnym przeciwieństwem tego, czego potrzebujemy, jest wzrost szczegółowości i barwności Emoji, a już na pewno straszliwą drogą jest pomysł z animoji, które wprowadza iOS 11. Miejmy nadzieję, że się nie przyjmą.

Ale nawet bez nich, dziś panuje bałagan. Microsoft PowerPoint będzie stosował płaskie, drukarskie emoji, ale Word już nie. Bez ręcznego ustawienia koloru na czarny, domyślnie Word wstawi do tekstu kolorowe symbole, co jest zaskakujące z wielu powodów. Po pierwsze, świadczy o wysokiej dowolności (a raczej samowolce) w implementacji obsługi rozszerzonych znaków w słynącym z wysokiej integracji pakiecie Office. Po drugie, PowerPoint jest o wiele bardziej pstrokatym programem, niż służący do statycznego tekstu Word, więc na intuicję powinny zachowywać się odwrotnie. Wreszcie, jak na przykładzie tego artykułu z Niebezpiecznika, emoji są nieprzewidywalne – nie wiadomo, czy za miesiąc nie przyjdzie aktualizacja, która podmieni szereg dotychczas monochromatycznych symboli na coś kolorowego i jakiś znak wykorzystywany do oddzielania sekcji w tekście zmieni się nagle na kolorowe serduszko. Co pozostanie niezauważone w dokumentach przez następne trzy miesiące. Rozwiązanie problemu wcale nie jest trywialne. Część emoji jest zaimplementowana w jednorodnej czcionce „Consolas”, stosowanej na potrzeby np. terminali, a także innych miejsc, gdzie zasadne jest użycie czcionki o stałej szerokości. Wszystkie emoji są w niej zapisane jako glify monochromatyczne. Ale czcionka o stałej szerokości nie może być ścieżką krytyczną dla szeryfowych krojów drukarskich! To niekoszerne. Musi być jakaś metoda, by sprawić, że czcionka będzie „wiedzieć”, że teraz ma się wyświetlać kolorowo, a kiedy indziej – monochromatycznie. Sprawa się zatem komplikuje. Czcionka obsługująca emoji musi trzymać wersję „drukarską” dla płaskiego tekstu oraz kolorową, na potrzeby komunikatorów, sieci społecznościowych i całej gamy świecidełek. Czy standard TrueType, dostarczający kontener dla fontów wektorowych, w ogóle obsługuje takie coś? Przecież kolorowe czcionki to jakaś herezja. Można było zmienić w maszynie do pisania całą tasiemkę na kolorową, ale różne kolory w jednym znaku? Skandal!

[img=Screenshot(19)]

Istotnie, TTF domyślnie nie obsługuje takiego wynalazku. Jakże więc Windows potrafi wyświetlać Emoji na prawach zwykłego tekstu? W jaki sposób wyświetlają się wszędzie indziej? Temat robi się zatem jeszcze bardziej skomplikowany: otóż mimo, że każde Emoji to „znak” zdefiniowany w Unicode, to niektóre środowiska wyświetlają Emoji poprzez ukryte wstawienie rastrowego obrazka. Windows 8 (i nowsze) radzi sobie jednak jeszcze lepiej. Przy okazji wystawia świadectwo potwierdzające geniusz i przewidywalność ludzi stojących za standardami Type 1 PostScript oraz TrueType. A więc „typografistów” stojących po obu stronach barykady (PostScript to wynalazek Adobe, TrueType powstał wskutek intrygującej współpracy Microsoftu z Apple, celem stworzenia konkurencji). Otóż Windows 8 dodaje niestandardowe, ale zgodne w dół, rozszerzenie zbioru TTF w postaci tablicy COLR przechowujące informacje o warstwach kolorystycznych symboli. To bardzo ciekawe podejście. Przede wszystkim, dla implementacyjnych purystów, tak stworzone czcionki TTF dalej są poprawne i zapisany w nich tekst – czytelny. Więc jeżeli COLR stanie się kolejnym standardem de facto pochodzącym z Redmond, nie stanie się to w atmosferze skandalu i naginania/łamania specyfikacji. Problem nie leży zatem w czcionkach. Źródłem kłopotów są programy, które decydują się z nich korzystać.

Tak naprawdę wcale nie jest takie oczywiste, jak Word powinien się zachować. Jeżeli domyślnie żądałby czcionki w czarnym kolorze (w takiej sytuacji otrzymuje się „drukarskie” emoji), to w jaki sposób możliwe byłoby wklejanie jednak wersji kolorowej? Word nie może domyślnie ustawiać koloru czcionki, domyślnie ustawiony kolor jest „żaden” (Kolor czcionki: Automatycznie), to okoliczności w postaci kartki papieru sprawiają, że jest czarny. Ale te okoliczności można zmienić. Zatem jeżeli chcemy być pewni, że dostaniemy monochromatyczne emoji, najlepiej profilaktycznie ustawić kolor całego tekstu na czarny.

Czemu PowerPoint zachowuje się inaczej? Jakkolwiek jasne i oczywiste jest, że nadaje się on o wiele bardziej do kolorowych obrazków, jak Emoji, to jego możliwości edycji tekstu są zredukowane w porównaniu z Wordem. W praktyce oznacza to, że nie istnieje automatyczne formatowanie i kolor tekstu w PowerPoint’cie zawsze jest jakiś: na domyślnych slajdach jest czarny. Zażądanie koloru od czcionki wymusi zatem zaserwowanie glifu monochromatycznego, co da efekt taki, jak w wierszu poleceń albo Notatniku: jednorodnie czarny znak przygotowany do czystego wydruku. Ten zabawny skutek uboczny pozbawia najpopularniejszą aplikację do tworzenia slajdów pewnego intrygującego podzbioru funkcjonalności…

W przeglądarkach internetowych ten problem jest jeszcze bardziej rozbudowany. Nie istnieje rozsądne zachowanie domyślne. Nie da się z przekonaniem powiedzieć, jak powinna się zachowywać przeglądarka. Domyślnie kolorować? Czy nie? Jak tym sterować? Istnieją metody wymuszenia „drukarskich” Emoji, poprzez zażądanie konkretnej czcionki w CSS albo poprzez nałożenie stylu bezpośrednio na tekst. Natomiast brak zachowania domyślnego oznacza, że każdy tekst z emoji należy świadomie i aktywnie kontrolować pod kątem wyświetlania. Poleganie na aplikowaniu ustawień domyślnych może prowadzić do różnych przygód, jak wspomniane wyżej przygody z różnym wyświetlaniem tego samego artykułu na przestrzeni lat.

Jest jeszcze jedna kwestia związana z obniżaniem czytelności tekstu i nie chodzi w niej o kolory, a o detale. Kolejne wersje Unicode wprowadzają coraz więcej symboli do opisywania emocji. Mamy już nie tylko uśmiechniętą buźkę, ale także zakochaną uśmiechniętą buźkę (U+1F60D); uśmiechniętą buźkę z radośnie zamkniętymi oczami (U+1F604); radośnie zakłopotaną twarz (U+1F605) oraz zestresowaną-zakłopotaną twarz (U+1F630). Przy takiej skali szczegółowości, zamiast widzieć „buźkę”, trzeba mrużyć oczy i wyłapywać detale niezbędne do zrozumienia, jaka treść miała być przekazana danym piktogramem. A to dopiero początek spirali złożoności. Kolejne Emoji dostarczają nam przedstawicieli wielu typowych zawodów, a najnowszy Unicode oferuje – a jakże! – sekwencje sterujące, modyfikujące płeć oraz kolor skóry. Gdzieś w USA zapewne odbyły się już, oprawione płonącymi radiowozami, protesty przeciwko rzekomemu forsowaniu w Emoji normatywności stereotypowych ról i ras względem podgrup historycznie ciemiężonych, co wymagało pilnego rozwiązania tej kwestii i wydania nowej wersji UTF-8.

[img=DKrNPltVAAA4LpD]

Tymczasem im bardziej szczegółowy jest symbol, tym bardziej wykluczający jest w odbiorze. Doskonale tłumaczy to Scott McCloud: realistycznie przedstawiona twarz, której ilustracja jest zaopatrzona w zbiór wyraźnie zaakcentowanych cech szczególnych, jest przekazem zbyt specyficznym. Jeżeli ktoś będzie chciał przekazać, że jest smutny, to znak U+1F622 ‘CRYING FACE’ będzie się do tego nadawał o wiele bardziej, niż „smutna twarz ciemnoskórej nauczycielki w hidżabie”. Z pierwszym przekazem łatwo się identyfikować, tymczasem klasyfikatory, w które bogaty jest drugi przekaz znacznie to utrudniają. Informacja, że ktoś jest nauczycielem przeszkadza mi w przetworzeniu informacji o tym, że jest smutny. Łatwiej nam podczas czytania poczuć się kimś smutnym, a o wiele trudniej jest poczuć się smutną nauczycielką. W hidżabie. Podobnie, acz nieco mniej, utrudnione będzie wczuć się w czyjś stan, gdy swoje słowa „I’m so high!” opatrzy symbolem „lewitujący mężczyzna w garniturze” (U+1F574, 'MAN IN BUSINESS SUIT LEVITATING', sic!). Mam nadzieję, że udaje mi się skutecznie przekazać swą myśl.

Dostrzegam ryzyko, że niedługo zaczniemy sobie robić krzywdę technologią, która w tak wielu kwestiach była genialnym i nieskończenie wartościowym, przydatnym rozwiązaniem. I że będzie to krzywda wyrządzona nie z pędu za pieniędzmi ze sprzedaży kolorowych obrazków, ani nawet nie z politycznie nadgorliwych pobudek prowadzących do definiowania koloru skóry w czcionce. Będzie to efekt zwykłej, dekadenckiej wręcz nudy. Zabawa z emoji musi dotrzeć do tego samego punktu, w którym znalazły się już gry komputerowe i interfejsy użytkownika. To może zająć jeszcze sporo czasu: do obsadzenia pozostało jeszcze 850 tysięcy symboli. A mój telefon z zeszłego roku dalej nie obsługuje połowy tych, które już obsadzono. Mój pecet nie potrafił nawet poprawnie wyświetlić dinozaura!

Niniejsze środowisko publikacji nie jest technicznie wyrozumiałe dla tematów tak postrzelonych jak ten, przez co konieczne było obranie tekstu z potencjalnie zabójczych symboli. Dla chętnych przygotowałem jednak wersję PDF, która zawiera wszystkie niestandardowe, ominięte symbole i obsługuje Emoji. Każdy, kto przeczytał choć pobieżnie tekst, powinien się domyślić, jakim hasłem chroniony jest dokument. Kto napisze w komentarzach, ten psuje zabawę :)

Dodam też, że wersja PDF stosuje dinozaury drukarskie. Oryginał, w postaci pliku DOCX, wyświetla je w kolorze (co ciekawe, na Androidzie nie)!