# Fontowe ABC

Co jakiś czas na liście dyskusyjnej GUST-u padają głosy świadczące z jednej strony o dużym zainteresowaniu sprawami fontowymi, a z drugiej strony -- o częstym niezrozumieniu podstawowych spraw związanych z fontami.

Zainteresowanie fontami jest o tyle uzasadnione, że ostatnimi czasy pojawia się na rynku coraz więcej fontów PostScript-owych, dajšcych się wykorzystać do składania polskich tekstów – ot, choćby fonty dystrybuowane przez firmę ThETA.

Te aspekty skłoniły nas do podjęcia próby spisania fontowego elementarza dla tych dzielnych adeptów fontologii, którzy nie boją się pułapek, od których niestety aż się roi w świecie fontów. (Dodatkowe informacje na temat wykorzystania fontów w LaTeX2e można znaleźć w dokumentacji Fonty w LaTex2e).

- Fonty „TeX-owe” czyli pliki TFM
- Fonty „właściwe”
- Fonty rodziny Computer Modern
- Fonty bitmapowe
- Fonty PostScript-owe czyli pliki AFM oraz PFB (lub PFA)
- Reprezentacja znaków
- Nazwy i kody znaków
- Konwersja AFM -> TFM
- Konwersja AFM -> TFM – poprawność nazw znaków
- Konwersja AFM -> TFM – kerny i ligatury
- Pliki konfiguracyjne sterownika `DVIPS`
- Łatanie fontów – niepoprawny font
- Łatanie fontów – brak plików AFM
- Casus ThETA
- Podsumowanie

## Fonty „TeX-owe” czyli pliki TFM

TeX-owi jest absolutnie obojętne, jakich fontów używamy: czy to są mapy bitowe, fonty PostScript-owe w formacie Type 1, czy też może egzotyczne fonty „własnego chowu” – nie ma to znaczenia. Jedyne, czego potrzebuje TeX, to informacja metryczna, czyli pliki `TFM` (TeX Font Metric). Pliki metryczne, jak sama nazwa wskazuje, zawierają w pierwszym rzędzie informację o rozmiarach znaków, ale także informację o wielkości kernów (podcięć) dla par znaków, informację o wielkości korekty kursywy (italic correction dla poszczególnych znaków oraz – choć trudno to zakwalifikować jako informację metryczną – informację o ligaturach, tzn. informację, które pary znaków mają być zastępowane automatycznie innym znakiem, np. dwa umieszczone obok siebie znaki `--` zamienione zostaną przez TeX-a przez pojedynczy znak „–” zwany pauzą półfiretową (endash).

Krótko mówiąc żeby w ogóle „prze-TeX-ować” dokument potrzebne są pliki `TFM`.

Spis treści

## Fonty „właściwe”

Dopiero sterowniki zamieniając złożone dokumenty, czyli pliki `DVI`, na postać widoczną już to na papierze, już to na ekranie, już to na jakimś innym nośniku potrzebują tych „właściwych fontów”.

Spis treści

## Fonty rodziny Computer Modern

Zgodnie z konwencją przyjętą przez Donalda E. Knutha nazwy fontów rodziny Computer Modern zawierają formalny rozmiar fontu w punktach, np. `cmr10` (font 10-punktowy), `cmbx7` (font 7-punktowy), itp. Należy tu podkreślić, że font `cmr12` nie jest równoważny fontowi zdefiniowanemu jako `cmr10` `at` `12pt` – chociaż oba fonty mają wielkość 12 punktów, to jednak proporcje znaków w obu fontach są inne. Tę samą cechę dziedziczą oczywiście fonty wywodzące się z rodziny Computer Modern (Computer Concrete, `EC`, `PL`), a także fonty rodziny `Euler`, fonty cyryliczne, i inne fonty tworzone w duchu konwencji rodziny Computer Modern.

Zmiany proporcji wraz ze zmianą stopnia pisma są jak najbardziej uzasadnione, małe fonty powinny dla lepszej czytelności mieć nieco większe i szersze oczka minuskuł w stosunku do majuskuł. Niemniej jednak wydaje się, że Donald E. Knuth nieco przesadził z liczbą odmian fontów zmieniając co jeden punkt proporcje znaków.

W praktyce wystarczyłyby nie więcej niż cztery zakresy: pierwszy dla fontów mniejszych niż 8-punktowe, drugi dla fontów od 8 do 12 punktów, trzeci dla fontów od 12 do – powiedzmy – 24 punktów i wreszcie czwarty dla fontów tzw. nagłówkowych. Ostatni z wymienionych zakresów nie pojawia się w fontach `Computer` `Modern`. Font calowy `cminch`, przeznaczony do nagłówków, jest w istocie przeskalowanym proporcjonalnie fontem `cmssbx10`. Innymi słowy dokładnie ten sam efekt uzyskałoby się za pomocą instrukcji `\font` `\f` `cminch` `\f` i za pomocą instrukcji `\font` `\f` `cmssbx10` `at` `1.44in` `\f`. Jedyna różnica polega na tym, że font `cminch` jest nieco „oszczędniejszy” – zawiera tylko duże litery i cyfry.

Sporo zamieszania wywołały także `plain`-owe instrukcje `\magstephalf` i `\magstep` sugerujące, że jedyne „legalne” powiększenia fontów to 109,5%, 120%, 144%, 172,8%, 207,4% lub co najwyżej 248,8% (p. The TeX book, str. 17). Mimo iż nie jest to nigdzie expressis verbis powiedziane, to jednak sporo nieporozumień narosło na tym tle. Trudno się temu dziwić, skoro prawie wszystkie pakiety zawierające fonty TeX-owe w postaci map bitowych (p. niżej) stosowały się do tej reguły, tzn. mapy bitowe generowane były tylko dla wymienionych wyżej powiększeń. Chcąc w dokumentach TeX-owych w sposób jednolity korzystać z fontów tradycyjnych, czyli bitmapowych, i z fontów PostScript-owych, nie należy przejmować się zanadto rozpowszechnionym obyczajem mającym swe korzenie w czasach, gdy komputery były wolniejsze i wygenerowanie fontu „od ręki” było zbyt kosztowne. Rzadko używana instrukcja postaci

       \font... at ...

jest w tym kontekście godna polecenia.

Spis treści

## Fonty bitmapowe

W tradycyjnej konfiguracji systemu TeX podstawowymi fontami są mapy bitowe (pliki `GF` – generic font) generowane przez program METAFONT. Najczęściej używanym formatem jest jednak nie format `GF`, a nieco oszczędniejszy format `PK` (packed). Do zamiany służy program `GFTOPK`, z reguły wywoływany automatycznie w procesie generowania fontów.

Fonty bitmapowe generowane są dla konkretnej wielkości pisma i konkretnego urządzenia, tzn. zawierają pewne informacje pozwalające na danym urządzeniu – ekranie czy drukarce – uzyskać optymalny wygląd znaków. Stąd np. odrębne fonty dla drukarek laserowych i drukarek atramentowych o tej samej rozdzielczości 300dpi.

TeX – jak już wspomnieliśmy – pozwala skalować całość dokumentu lub poszczególne fonty:

    \magnification2000
    \font\A plr10 scaled \magstep3
    \font\B plr10 at 28.5pt

gdzie `plr10` oznacza nazwę fizycznie posiadanego na dysku pliku `plr10.tfm`. TeX przeskaluje font `plr10` tak, jak sobie tego życzymy, a ściślej – przeskaluje informację metryczną związaną z fontem. Żeby móc zobaczyć, jak wyglądają znaki przeskalowanego fontu, należy skorzystać z METAFONT-a, który oczywiście potrafi generować fonty dowolnie przeskalowane.

Fonty `PK` zwykle przechowywane są w katalogach o nazwach zawierających liczbę wynikającą z przemnożonenia rozdzielczości przez przeskalowanie, np. fonty o rozdzielczości 300dpi ( dots per inch) powiększone o 20% (`\magstep1`) znajdą się w katalogu o nazwie `360dpi`, `dpi360` lub jakimś innym, podobnie nazwanym. Jeśli system operacyjny zezwala na nadawanie plikom długich nazw, to przeskalowanie może być wpisane w nazwę pliku, np. `.../fonts/pk/laserjet/pl/plr10.360pk`.

Standardowe sterowniki przetwarzające pliki `DVI` czy to na postać wyświetlaną na ekranie, czy też drukowaną, używają fontów `PK` i posiadają mechanizm przeszukiwania odpowiedniej struktury katalogów lub interpretacji nazw fontów przeskalowanych. Sterowniki te pozwalają zwykle na bardzo szybkie wyświetlenie składanego tekstu. Współczesne sterowniki posiadają także możliwość współpracy z METAFONT-em – potrafią przekazać informację o brakujących fontach i uruchomić METAFONT-a, wstrzymując pracę do czasu zakończenia procesu generowania brakujących fontów. Dzięki temu nie ma obecnie potrzeby trzymania na dysku olbrzymich bibliotek fontów w formacie `PK`, wystarczą pliki źródłowe fontów i odpowiednio skonfigurowane łącze sterownik-METAFONT (program lub skrypt) by zautomatyzować proces generowania fontów. Dla bardzo rozpowszechnionych sterowników z pakietu `emTeX` będzie to program `MFjob` (`MS-DOS`, `OS/2`), zaś dla systemów opartych na `web2c` – skrypt `mktexpk` (różne wersje `Unix`, `Windows` i `Amiga`).

Spis treści

## Fonty PostScript-owe czyli pliki AFM oraz PFB (lub PFA)

Jeżeli chodzi o PostScript, to ten „właściwy font” – mowa tu o fontach zapisanych w formacie Adobe Type 1 – zawarty jest w pliku z rozszerzeniem `.pfb` (PostScript Font Binary) lub `.pfa` ( PostScript Font ASCII). Natomiast o plikach `TFM` w świecie PostScript-owym mało kto słyszał. Na szczęście dobrzy ludzie z firmy Adobe wymyślili coś podobnego do tego, co wymyślił Donald E. Knuth, mianowicie pliki metryczne AFM (Adobe Font Metric). Różnią się one trochę od plików `TFM` (np. pliki `AFM` są plikami tekstowymi), ale mimo różnic jest możliwe by na podstawie pliku `AFM` utworzyć plik `TFM`.

Spis treści

## Reprezentacja znaków

Zanim pójdziemy dalej trzeba wyjaśnić jedną rzecz, mianowicie w jaki sposób są reprezentowane znaki. Jeżeli chodzi o plik `DVI` to odpowiedź jest trywialna: jako liczby z zakresu `0`--`255`. Przy tworzeniu pliku PostScript-owego za pomocą sterownika sytuacja nie ulega zmianie, to znaczy w pliku PostScript-owym znaki też są reprezentowane w zasadzie jako liczby z zakresu `0`--`255`, czasem w reprezentacji ASCII, a czasem w reprezentacji ósemkowej. Natomiast we „właściwym foncie” PostScript-owym, podobnie zresztą jak w foncie METAFONT-owym, jest inaczej: znaki są zasadniczo reprezentowane za pomocą nazw w rodzaju „period”, „periodcentered”, „lslash”, „aogonek”, itp.

Formalnie rzecz biorąc font PostScript-owy jest programem, a nazwy znaków są nazwami podprogramów opisujących kształt znaków za pomocą – znów podobnie jak w programach METAFONT-owych – krzywych trzeciego stopnia, zwanych krzywymi Béziera. Dodatkowo podprogramy te opisują niektóre szczegóły procesu zamiany obwiedni na mapy bitowe (tzw. hinty czyli podpowiedzi), bo przecież ostatecznie znak zostanie wyświetlony na ekranie, wydrukowany na drukarce lub naświetlony na diapozytywie, czyli musi zostać zamieniony na postać dyskretną.

Spis treści

## Nazwy i kody znaków

Skąd zatem PostScript trafiając na jakąś liczbę „wie”, że ma użyć procedury o nazwie, powiedzmy, „aogonek”?

Aaa, właśnie! Tu jest pies pogrzebany. We „właściwym foncie” PostScript-owym jest zawarta dodatkowa informacja, mianowicie tabela par (liczba, nazwa) przyporządkowująca liczbom z zakresu `0`--`255` nazwy podprogramów opisujących znaki. Tablica ta (czasem zwana wektorem) nosi nazwę „Encoding”, co jest może mało istotne, natomiast istotne jest to, że tablicę tę można „w locie” zmienić. Z tej możliwości korzysta m.in. sterownik `DVIPS` (p. niżej).

## Konwersja AFM -> TFM

W pliku AFM znajduje się również informacja o przyporządkowaniu liczba-nazwa, (w zasadzie można zakładać, że jest to to samo przyporządkowanie, co w pliku `PFB`/`PFA`). Na ogół nie jest to przyporządkowanie, o które by nam chodziło. Ale nie ma biedy – `DVIPS`-owi można podać dowolne przyporządkowanie, które zostanie użyte w tworzonym przezeń pliku PostScript-owym.

Konwertery `AFM->TFM` na podstawie nazw generują stosowne przyporządkowanie, lub nawet wiele przyporządkowań, a dla każdego z takich przyporządkowań tworzony jest odpowiadający mu plik `TFM`.

Najpowszechniej używanym konwerterem jest program `AFM2TFM`, należący do standardowej dystrybucji sterownika `DVIPS`. Konwerter o nazwie TOIL, bazuje na programach `AWK` oraz METAFONT Warto też wspomnieć o pakiecie `VFINST`, oferującym liczne możliwości, bazującym na fontach wirtualnych.

Spis treści

## Konwersja AFM -> TFM – poprawność nazw znaków

Aby konwertery `AFM->TFM` mogły działać jak należy, nazwy podprogramów muszą być zgodne z ich treścią. Tak niestety nie zawsze jest, np. pod nazwą „Sterling” zamiast opisu znaku funta można znaleźć opis polskiego „Ł” czyli „Lslash”. Pomysłów na cudaczne nazewnictwo jest mniej więcej tyle, ile tzw. standardów kodowania znaków, czyli infinity.

Z niepoprawnymi nazwami można sobie poradzić. Co nam zależy, przecież „onesuperior” brzmi równie ładnie jak „aogonek”, nieprawdaż? Problem jedynie w tym, że z góry nie wiadomo, że producent uznał „onesuperior” za odpowiednią nazwę dla polskiej litery „ą”. We wspomnianych fontach firmy ThETA (p. niżej) akurat tak jest, ale tak bynajmniej być nie musi, w końcu jakiś szaleniec może się pogodzić z propozycją Adobe i użyć dla podprogramu opisującego „ą” nazwy „aogonek”…

Jakby nie dość było problemów, oprócz nazewnictwa ewidentnie niepoprawnego możemy się zetknąć z obocznością! Otóż niektórzy producenci dla określenia znaków „ż” i „Ż” używają nazw „zdot” i „Zdot”, a niektórzy „zdotaccent” i „Zdotaccent”. Nie znalazłem jednoznacznego stanowiska firmy Adobe w tej sprawie, ale na ogół obowiązuje zasada „sklejania” nazw: „a” + „grave” = „agrave”; skoro więc istnieje znak „dotaccent” (nazwa używana przez Adobe), to „ż” należy rozumieć jako „z” + „dotaccent” czyli „zdotaccent”. Innymi słowy zalecać by należało używanie nazw „zdotaccent” i „Zdotaccent”, ale być może konwertery `AFM->TFM` powinny być uwrażliwione na tę oboczność.

Spis treści

## Konwersja AFM -> TFM – kerny i ligatury

Plik `TFM` zawiera jeszcze informację o parach kernowych i ligaturach. Pary kernowe, uwzględniane „jak leci” przez większość konwerterów `AFM->TFM`, na ogół są umieszczane jak należy w plikach `AFM`, chociaż czasami można trafić na felerne pliki `AFM` bez par kernowych. Obecność par kernowych poznajemy to po występowaniu wierszy zaczynających się od słowa kluczowego „KPX”. Warto mieć na uwadze, że bywają pliki `AFM` posiadające tylko część par kernowych – np. znaki diakrytyczne czasami nie są uwzględniane – dobrze jest sprawdzić plik `AFM` pod tym kątem.

Z ligaturami jest znacznie gorzej – można je bardzo rzadko uświadczyć, mimo iż teoretycznie format `AFM` pozwala na definiowanie ligatur, np. poniższy przykładowy wiersz pliku `AFM`:

       C 45; WX 329; N hyphen; B 17 188 313 303; L hyphen endash;

zgodnie ze specyfikacją Adobe ustala, że znak o kodzie `45` ma szerokość `329` jednostek (jednostka = 1/1000em), nosi nazwę „hyphen”, że naroża prostokąta ograniczającego obrys znaku mają współrzędne wynoszące w tych samych jednostkach (17, 188) oraz (313, 303), i wreszcie że dwa znaki „hyphen” mają być zamieniane na znak o nazwie „endash”, czyli innymi słowy znak o nazwie „endash” jest ligaturą dwóch znaków o nazwie „hyphen”.

W związku z powszechnym brakiem informacji o ligaturach w plikach `AFM`, konwertery `AFM->TFM` muszą albo się domyślić, jakie by tu ligatury można wstawić, albo – co chyba jest lepszym rozwiązaniem – zostać poinformowane o prawidłowych dla danego fontu (grupy fontów) ligaturach.

Spis treści

## Pliki konfiguracyjne sterownika `DVIPS`

Popularny sterownik `DVIPS`, autorstwa Tomasa Rokickiego, zamieniający pliki `DVI` na pliki PostScript-owe musi wiedzieć – podobnie jak każdy sterownik – gdzie znajdują się fonty TeX-owe i PostScript-owe. Informację tę zawierają pliki `config.ps` i `psfonts.map`, poszukiwane w kartotekach wskazywanych przez zmienną systemową `TEXCONFIG` (we współczesnych instalacjach zmienna ta jest już zwykle zadeklarowana w pliku konfiguracyjnym `texmf.cnf`).

Plik `config.ps` zawiera informacje o parametrach pracy programu. Natomiast plik `psfonts.map` zawiera informacje związane wyłącznie z dostępnymi w danej instalacji fontami PostScript-owymi. W pliku `psfonts.map` informacje o poszczególnych fontach umieszczane są w jednym wierszu (co czasem może być kłopotliwe). Typowy wiersz wygląda następująco:

    ec-qplr TeXGyrePagella-Regular "encqec ReEncodeFont" <q-ec.enc <qplr.pfb

Pierwsza pozycja określa nazwę TeX-ową fontu, druga – wewnętrzną nazwę PostScript-ową fontu (robi z niej użytek interpreter PostScript-u), następnie pojawia się informacja o dodatkowych zabiegach, jakim ma być poddany font (może to być poziome przeskalowanie fontu, pochylenie lub zmiana kodowania – w podanym przykładzie chodzi o zmianę kodowania), a na końcu pojawiają się nazwy plików, które mają zostać dołączone do pliku wynikowego – w tym wypadku jest to plik kodowania `q-ec.enc` oraz font `qplr.pfb`.

Podanie nazwy pliku fontowego nie jest konieczne – w takim wypadku `DVIPS` założy, że chodzi o font wbudowany w urządzenie. Gorąco odradzamy korzystanie z tej możliwości – opłakane skutki korzystania z fontów wbudowanych można co jakiś czas oglądać w materiałach nawet renomowanych firm: a to zamiast polskich znaków występują „krzaczki”, a to litery zachodzą na siebie, a to skład się zupełnie rozjeżdża…

Plik kodowania zawiera tablicę 256 nazw znaków, określającą omawiane wyżej przyporządkowanie kod-nazwa. Jest to w istocie fragment kodu PostScript-owego postaci:

      /encqec[
      /grave
      /acute
      /circumflex
      ...
      /thorn
      /germandbls
      ] def

O tym, jaki kod otrzymuje dany znak, decyduje kolejność wystąpienia: w tym przypadku na pozycji zerowej (w języku PostScript liczenie zawsze odbywa się od zera) występuje znak o nazwie `grave` (znak „ciach” `/` w notacji PostScript-owej oznacza mniej więcej to samo co znak „w-tył-ciach” `\` w notacji TeX-owej),znak `acute` otrzymuje kod 1, znak `circumflex` – kod 2, …, znak `thorn` – kod 254, i wreszcie znak `germandbls` – kod 255. Wystąpienie `.notdef` oznacza, że w foncie nie ma znaku na pozycji o danym kodzie.

Warto mieć świadomość, że `DVIPS` włącza wszelkie pliki prawie ich nie analizując, jedyny zabieg przezeń wykonywany to zamiana postaci binarnej fontu Type 1 (`PFB`) na postać ASCII (`PFA`). Jeżeli font jest już w postaci ASCII, to włączany jest do dokumentu „jak leci”, bez żadnej ingerencji ze strony sterownika. Oznacza to, że używając `DVIPS`-a możemy korzystać ze wszystkich możliwych fontów PostScript-owych, nie tylko najbardziej popularnych fontów Type 1, ale w szczególności także fontów TrueType, które dla interpretera PostScript-u są po prostu fontami Type 42 – wystarczy mieć plik `TFM` i font Type 42 w postaci ASCII.

Spis treści

## Łatanie fontów – niepoprawny font

Używając różnych wymyślnych narzędzi (np. T1UTIL Lee Hetheringtona) można się zorientować, jakim znakom zostały przypisane jakie nazwy i w razie czego je poprawić, można też uzupełniać kerny, itp., ale to jest żmudne i przykre, bo niepotrzebne zajęcie.

Spis treści

## Łatanie fontów – brak plików AFM

Czasem fonty PostScript-owe są dystrubuowane z plikami `PFM` (Printer Font Metric) zamiast z plikami AFM.

Brak plików `AFM` praktycznie przekreśla możliwość użycia fontu PostScript-owego w TeX-u, bowiem pliki `PFM` zawierają znacznie uboższą informację niż pliki AFM, w szczególności nie zawierają nazw znaków, czyli nie określają żadnej tablicy kodowania ( encoding vector, p. wyżej). Można zakładać, że chodzi o takie samo przyporządkowanie, jakie jest wpisane w pliku `PFB`/`PFA`, chociaż w ogólności tak być nie musi. Ponadto w pliku `PFM` znajdują się dane na temat par kernowych jedynie dla co najwyżej 256 znaków, a font PostScript-owy może ich zawierać nacznie więcej.

Jeśli jednak szczęście nam dopisze, to z plików `PFM` oraz `PFB` (bądź `PFA`) możemy odtworzyć informację niezbędną do utworzenia pliku `AFM` – można spróbować użyć pakietu pf2afm, który dostępny jest w archiwum GUST-u.

Spis treści

## Casus ThETA

Ostatnio na rynku polskim pojawiły się godne uwagi polonizacje fontów firmy BitStream, sygnowane przez firmę ThETA.

Niestety firma ThETA wyraźnie zignorowała rynek TeX-owy, chociaż może i słusznie zignorowała, skoro TeX-owców jakoś nie widać i nie słychać, no może z wyjątkiem kilkorga spośród 150 niegroźnych wariatów zapisanych do GUST-u…

Otóż firma ThETA wydała jak do tej pory 3 płyty CD z fontami, każda kolejna płyta zawierała inne fonty i była coraz mniej przydatna dla TeX-owców:

- Pierwsza płyta (cena ok. 500 zł) miała nazwy znaków w zasadzie poprawne z dokładnością do „zdot” zamiast „zdotaccent”. To zapewne spowodowało, że płyta ta ochrzczona została „TeX-ową” przez ludową tradycję, że tworzenie plików `TFM` przebiegało bezboleśnie i że używanie ich pod Ghostscriptem nie wróżyło niebezpieczeństw. Niestety, fonty nie były formalnie poprawne, co powodowało, że niektóre RIP-y PostScript-owe sygnalizowały błąd podczas przetwarzania tych fontów.
- Niepoprawność formalna polegała na braku w tych fontach wymaganego przez dokumentację Adobe podprogramu (znaku) o egzotycznej nazwie „.notdef”. (Podprogram ten jest używany, gdy z jakichś powodów program PostScript-owy odwołuje się do znaku, którego nie ma w foncie; w większości fontów jest to znak nie zawierający żadnego elementu graficznego, odpowiadający w zasadzie spacji.)
- Było też drugie wydanie pierwszej płyty, „poprawione” w duchu opisanej niżej drugiej płyty.
- Z drugą płytą (cena ok. 450 zł) było lepiej jeżeli chodzi o znak „.notdef”, natomiast gorzej, jeśli chodzi o nazwy znaków. Oto errata:

  JEST | WINNO BYĆ
  ordmasculine | ae
  ordfeminine | AE
  tilde | ecircumflex
  circumflex | Ecircumflex
  onequarter | ntilde
  logicalnot | Ntilde
  c157 | oe
  c141 | OE
  cent | questiondown
  florin | Ydieresis
  c142 | Zcaron
  c158 | zcaron
  onesuperior | aogonek
  yen | Aogonek
  ae | cacute
  AE | Cacute
  ecircumflex | eogonek
  Ecircumflex | Eogonek
  threesuperior | lslash
  sterling | Lslash
  ntilde | nacute
  Ntilde | Nacute
  oe | sacute
  OE | Sacute
  questiondown | zdotaccent
  macron | Zdotaccent
  Ydieresis | zacute
  c143 | Zacute

- Indagowany na tę okoliczność autor polonizacji Jakub Tatarkiewicz stwierdził, że tak jest dobrze, i że nie będzie dla paru zapaleńców przygotowywał specjalnej „TeX-owej” (czyt.: poprawnej) wersji.
- Z trzecią płytą (cena ok. 300 zł) jest zdecydowanie najgorzej, bo firma ThETA wyposażyła je jedynie w pliki `PFM`.

Na szczęście dla TeX-owców „podłatanie” fontów ThETA nie jest trudne. W archiwum GUST-u znajduje się pakiet THETAFIX, korzystający ze wspomnianych programów Lee Hetheringtona oraz programu `AWK` (w wersji GNU), dokonujący stosownych zmian w plikach składających się na fonty PostScript-owe z dwóch pierwszych płyt. Trzecią płytę można podłatać za pomocą wspomnianego pakietu pf2afm.

Po takich poprawkach i utworzeniu plików `TFM` większość fontów powinna się dać bez kłopotów używać w dokumentach TeX-owych. Niestety większość, a nie wszystkie, bowiem kilkaset fontów z pierwszych dwóch płyt można pogrupować w kilkadziesiąt różnych klas, w zależności od zestawu znaków. Pakiet THETAFIX jest przystosowany do jednej z klas, tej najbardziej licznej. Ale w złośliwych przypadkach coś może nie zadziałać – kłopoty są ceną, jaką się płaci za tanie fonty… Tak, tak, 1000 zł za kilkaset fontów to stosunkowo tanio.

Spis treści

## Podsumowanie

Warto pamiętać, że font nie tylko musi ładnie w druku wyglądać, ale i jego dość skomplikowana „wewnętrzna” struktura musi być zrobiona porządnie.

Jednym z najbardziej dających się we znaki problemów jest problem układu znaków w foncie. Staranne przemyślenie tego problemu musi prowadzić do wniosku, że firma Adobe już dawno temu znalazła wystarczające w większości przypadków rozwiązanie problemu konfigurowalności układu znaków w foncie. To bardzo mocny argument na rzecz korzystania z fontów PostScript-owych w formacie Type 1.

Wprawdzie detale związane z instalowaniem fontów mogą się wydawać skomplikowane, ale taka jest natura rzeczy. A do czego prowadzi próba ukrycia tej natury przed użytkownikiem, wielu z nas boleśnie odczuło w przypadku korzystania fontów TrueType w systemie Windows. Wprawdzie instaluje się je bardzo prosto (albo i – nie wiedzieć czemu – nie instaluje), ale praktycznie nie ma żadnej możliwości rekonfiguracji. Ktoś, kto przenosił fonty TrueType z jednej wersji systemu Windows do innej, wie o czym mowa – a to font się w ogóle nie daje zainstalować, a to inne znaki się pojawiają, niż byśmy chcieli, a to nasza ulubiona aplikacja albo tego fontu nie widzi, albo się na nim wywraca…

Mając to na względzie uważamy, że warto poświęcić nieco czasu i wysiłku na zrozumienie podstaw konfigurowania fontów, zwłaszcza fontów PostScript-owych w formacie Adobe Type 1 – to naprawdę w pewnym momencie staje się proste, a tym samym oczywiście niezwykle użyteczne.

Spis treści

Bogusław Jackowski i Staszek Wawrykiewicz

Powyższy tekst jest zmodyfikowaną wersją artykułu z Biuletynu GUST, nr 8/1997, s. 7–12.
Ostatnie zmiany 6.03.2008