The hardware and bandwidth for this mirror is donated by dogado GmbH, the Webhosting and Full Service-Cloud Provider. Check out our Wordpress Tutorial.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]dogado.de.

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.

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

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 „ą”. 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

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 5.05.2014

These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.
Health stats visible at Monitor.