summaryrefslogtreecommitdiff
path: root/Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html
diff options
context:
space:
mode:
Diffstat (limited to 'Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html')
-rw-r--r--Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html671
1 files changed, 671 insertions, 0 deletions
diff --git a/Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html b/Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html
new file mode 100644
index 00000000000..2052b7953dc
--- /dev/null
+++ b/Master/texmf-doc/doc/polish/tex-virtual-academy-pl/fonty/font-abc.html
@@ -0,0 +1,671 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<html>
+<head>
+<meta http-equiv="content-type" content="text/html; charset=iso-8859-2">
+<meta name="keywords" lang="en" content="Polish TeX Users Group, Polish TeX, computer fonts" >
+<LINK REL=STYLESHEET TYPE="text/css" HREF="./tpstyle.css">
+<title> Fontowe ABC </title>
+</head>
+<body>
+
+<h1> Fontowe ABC </h1>
+<P>
+Co jakiś czas na liście dyskusyjnej GUST-u padają głosy świadczące
+z&nbsp;jednej strony o&nbsp;dużym zainteresowaniu sprawami fontowymi,
+a&nbsp;z&nbsp;drugiej strony -- o&nbsp;częstym niezrozumieniu podstawowych
+spraw związanych z&nbsp;fontami.
+</P>
+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ę&nbsp;ThETA.
+</P>
+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&nbsp;świecie fontów. (Dodatkowe informacje na temat
+wykorzystania fontów w LaTeX2e można znaleźć w&nbsp;dokumentacji
+<A HREF="nfss.html">Fonty w&nbsp;LaTex2e</a>).
+
+<!-- Spis treści ....................................................... -->
+<hr>
+<A NAME=P0> <ul>
+ <li><A HREF=#Fonty-TFM> Fonty ,,TeX-owe'' czyli pliki TFM</A></li>
+ <li><A HREF=#Fonty-wlasciwe> Fonty ,,właściwe''</A></li>
+ <li><A HREF=#Fonty-CM> Fonty rodziny Computer Modern</A></li>
+ <li><A HREF=#Fonty-bitmapowe> Fonty bitmapowe</A></li>
+ <li><A HREF=#Fonty-PS> Fonty PostScript-owe czyli pliki AFM oraz PFB (lub PFA)</A></li>
+ <li><A HREF=#Znaki> Reprezentacja znaków</A></li>
+ <li><A HREF=#Nazwy-kody> Nazwy i kody znaków</A></li>
+ <li><A HREF=#AFMTFM> Konwersja AFM -> TFM</A></li>
+ <li><A HREF=#AFMTFMp> Konwersja AFM -> TFM -- poprawność nazw znaków</A></li>
+ <li><A HREF=#AFMTFMk> Konwersja AFM -> TFM -- kerny i&nbsp;ligatury</A></li>
+ <li><A HREF=#Pliki-cnf> Pliki konfiguracyjne sterownika <code>DVIPS</code></A></li>
+ <li><A HREF=#Latanie> Łatanie fontów -- niepoprawny font</A></li>
+ <li><A HREF=#BrakAFM> Łatanie fontów -- brak plików AFM</A></li>
+ <li><A HREF=#ThETA> Casus ThETA</A></li>
+ <li><A HREF=#Podsumowanie> Podsumowanie</A></li>
+</ul>
+<hr>
+
+<!-- ................................................................. -->
+<A NAME="Fonty-TFM"><h2>Fonty ,,TeX-owe'' czyli pliki TFM</h2>
+<P>
+TeX-owi jest absolutnie obojętne, jakich fontów używamy: czy to są
+mapy bitowe, fonty PostScript-owe w&nbsp;formacie Type&nbsp;1, czy też
+może egzotyczne fonty ,,własnego chowu'' -- nie ma to
+znaczenia. Jedyne, czego potrzebuje TeX, to informacja metryczna,
+czyli pliki <code>TFM</code> (TeX Font Metric). Pliki metryczne, jak
+sama nazwa wskazuje, zawierają w&nbsp;pierwszym rzędzie informację
+o&nbsp;rozmiarach znaków, ale także informację o&nbsp;wielkości kernów
+(podcięć) dla par znaków, informację o&nbsp;wielkości korekty kursywy
+(<em>italic correction</em> dla poszczególnych znaków oraz -- choć
+trudno to zakwalifikować jako informację metryczną -- informację
+o&nbsp;ligaturach, tzn.&nbsp;informację, które pary znaków mają być
+zastępowane automatycznie innym znakiem, np.&nbsp;dwa umieszczone obok
+siebie znaki <code>--</code> zamienione zostaną przez TeX-a przez
+pojedynczy znak ,,--'' zwany pauzą półfiretową (<em>endash</em>).
+</P>
+<P>
+Krótko mówiąc żeby w&nbsp;ogóle ,,prze-TeX-ować'' dokument potrzebne
+są pliki&nbsp;<code>TFM</code>.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Fonty-wlasciwe"><h2>Fonty ,,właściwe''</h2>
+
+Dopiero sterowniki zamieniając złożone dokumenty, czyli pliki
+<code>DVI</code>, 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''.
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Fonty-CM"><h2>Fonty rodziny Computer Modern</h2>
+<P>
+Zgodnie z&nbsp;konwencją przyjętą przez Donalda E.&nbsp;Knutha nazwy
+fontów rodziny Computer Modern zawierają formalny rozmiar fontu
+w&nbsp;punktach, np.&nbsp;<code>cmr10</code> (font 10-punktowy),
+<code>cmbx7</code> (font 7-punktowy), itp. Należy tu podkreślić, że
+font <code>cmr12</code> nie jest równoważny fontowi zdefiniowanemu
+jako <code>cmr10</code>&nbsp;<code>at</code>&nbsp;<code>12pt</code> --
+chociaż oba fonty mają wielkość 12&nbsp;punktów, to jednak proporcje
+znaków w&nbsp;obu fontach są inne. Tę samą cechę dziedziczą oczywiście
+fonty wywodzące się z&nbsp;rodziny Computer Modern (Computer Concrete,
+<code>EC</code>, <code>PL</code>), a&nbsp;także fonty rodziny
+<code>Euler</code>, fonty cyryliczne, i&nbsp;inne fonty tworzone
+w&nbsp;duchu konwencji rodziny Computer Modern.
+</P>
+<P>
+Zmiany proporcji wraz ze zmianą stopnia pisma są jak najbardziej uzasadnione,
+małe fonty powinny dla lepszej czytelności mieć nieco większe i&nbsp;szersze
+oczka minuskuł w&nbsp;stosunku do majuskuł. Niemniej jednak wydaje się, że
+Donald&nbsp;E.&nbsp;Knuth nieco przesadził z&nbsp;liczbą odmian fontów
+zmieniając co jeden punkt proporcje znaków.
+</P>
+<P>
+W&nbsp;praktyce wystarczyłyby nie więcej niż cztery zakresy: pierwszy
+dla fontów mniejszych niż 8-punktowe, drugi dla fontów od
+8&nbsp;do&nbsp;12&nbsp;punktów, trzeci dla fontów od 12&nbsp;do
+-- powiedzmy -- 24&nbsp;punktów i&nbsp;wreszcie czwarty dla fontów
+tzw.&nbsp;nagłówkowych. Ostatni z&nbsp;wymienionych zakresów nie
+pojawia się w&nbsp;fontach
+<code>Computer</code>&nbsp;<code>Modern</code>. Font calowy
+<code>cminch</code>, przeznaczony do nagłówków, jest w&nbsp;istocie
+przeskalowanym proporcjonalnie fontem <code>cmssbx10</code>. Innymi
+słowy dokładnie ten sam efekt uzyskałoby się za pomocą instrukcji
+<code>\font</code>&nbsp;<code>\f</code>
+<code>cminch</code>&nbsp;<code>\f</code> i&nbsp;za pomocą instrukcji
+<code>\font</code>&nbsp;<code>\f</code>
+<code>cmssbx10</code>&nbsp;<code>at</code>&nbsp;<code>1.44in</code>&nbsp;<code>\f</code>.
+Jedyna różnica polega na tym, że font <code>cminch</code> jest nieco
+,,oszczędniejszy''&nbsp;-- zawiera tylko duże litery i&nbsp;cyfry.
+</P>
+<P>
+Sporo zamieszania wywołały także <code>plain</code>-owe instrukcje
+<code>\magstephalf</code> i&nbsp;<code>\magstep</code> 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.&nbsp;<em> The TeX book</em>,
+str.&nbsp;17). Mimo iż nie jest to nigdzie <em>expressis verbis</em>
+powiedziane, to jednak sporo nieporozumień narosło na tym tle. Trudno
+się temu dziwić, skoro prawie wszystkie pakiety zawierające fonty
+TeX-owe w&nbsp;postaci map bitowych (p.&nbsp;niżej) stosowały się do
+tej reguły, tzn.&nbsp;mapy bitowe generowane były tylko dla
+wymienionych wyżej powiększeń. Chcąc w&nbsp;dokumentach TeX-owych
+w&nbsp;sposób jednolity korzystać z&nbsp;fontów tradycyjnych, czyli
+bitmapowych, i&nbsp;z&nbsp;fontów PostScript-owych, nie należy
+przejmować się zanadto rozpowszechnionym obyczajem mającym swe
+korzenie w&nbsp;czasach, gdy komputery były wolniejsze
+i&nbsp;wygenerowanie fontu ,,od ręki'' było zbyt kosztowne. Rzadko
+używana instrukcja postaci
+<pre>
+\font... at ...
+</pre>
+jest w&nbsp;tym kontekście godna polecenia.
+</p>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Fonty-bitmapowe"><h2>Fonty bitmapowe</h2>
+<P>
+W&nbsp;tradycyjnej konfiguracji systemu TeX podstawowymi fontami są
+mapy bitowe (pliki <code>GF</code> -- <em> generic font</em>)
+generowane przez program METAFONT. Najczęściej używanym formatem jest
+jednak nie format <code>GF</code>, a&nbsp;nieco oszczędniejszy
+format&nbsp;<code>PK</code> (<em>packed</em>). Do zamiany służy
+program <code>GFTOPK</code>, z&nbsp;reguły wywoływany automatycznie
+w&nbsp;procesie generowania fontów.
+</P>
+<P>
+Fonty bitmapowe generowane są dla <em>konkretnej wielkości pisma
+i&nbsp;konkretnego urządzenia</em>, tzn.&nbsp;zawierają pewne
+informacje pozwalające na danym urządzeniu -- ekranie czy drukarce --
+uzyskać optymalny wygląd znaków. Stąd np.&nbsp;odrębne fonty dla
+drukarek laserowych i&nbsp;drukarek atramentowych o&nbsp;tej samej
+rozdzielczości&nbsp;300dpi.
+</P>
+<P>
+TeX -- jak już wspomnieliśmy -- pozwala skalować całość dokumentu lub
+poszczególne fonty:
+</P>
+
+<pre>
+\magnification2000
+\font\A plr10 scaled \magstep3
+\font\B plr10 at 28.5pt
+</pre>
+gdzie <code>plr10</code> oznacza nazwę fizycznie posiadanego na dysku
+pliku <code>plr10.tfm</code>. TeX przeskaluje font <code>plr10</code>
+tak, jak sobie tego życzymy, a&nbsp;ściślej -- przeskaluje informację
+metryczną związaną z&nbsp;fontem. Żeby móc zobaczyć, jak wyglądają
+znaki przeskalowanego fontu, należy skorzystać z&nbsp;METAFONT-a,
+który oczywiście potrafi generować fonty dowolnie przeskalowane.
+</P>
+<P>
+Fonty <code>PK</code> zwykle przechowywane są w&nbsp;katalogach
+o&nbsp;nazwach zawierających liczbę wynikającą z&nbsp;przemnożonenia
+rozdzielczości przez przeskalowanie, np.&nbsp;fonty
+o&nbsp;rozdzielczości 300dpi (<em> dots per inch</em>) powiększone
+o&nbsp;20% (<code>\magstep1</code>) znajdą się w&nbsp;katalogu
+o&nbsp;nazwie <code>360dpi</code>,
+<code>dpi360</code> lub jakimś innym, podobnie nazwanym. Jeśli system
+operacyjny zezwala na nadawanie plikom długich nazw, to przeskalowanie
+może być wpisane w&nbsp;nazwę pliku,
+np.&nbsp;<code>.../fonts/pk/laserjet/pl/plr10.360pk</code>.
+</P>
+<P>
+Standardowe sterowniki przetwarzające pliki <code>DVI</code> czy to na
+postać wyświetlaną na ekranie, czy też drukowaną, używają fontów
+<code>PK</code> i&nbsp;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&nbsp;METAFONT-em -- potrafią przekazać
+informację o&nbsp;brakujących fontach i&nbsp;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&nbsp;formacie <code>PK</code>, wystarczą
+pliki źródłowe fontów i&nbsp;odpowiednio skonfigurowane łącze
+sterownik-METAFONT (program lub skrypt) by zautomatyzować proces
+generowania fontów. Dla bardzo rozpowszechnionych sterowników
+z&nbsp;pakietu <code>emTeX</code> będzie to program <code>MFjob</code>
+(<code>MS-DOS</code>, <code>OS/2</code>), zaś dla systemów opartych na
+<code>web2c</code> -- skrypt <code>MakeTeXPK</code> (różne wersje
+<code>U**X</code>, <code>Windows95</code> i&nbsp;<code>NT</code>,
+<code>Amiga</code>).
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Fonty-PS"> <h2>Fonty PostScript-owe czyli pliki AFM oraz PFB (lub PFA)</h2>
+<P>
+Jeżeli chodzi o&nbsp;PostScript, to ten ,,właściwy font'' -- mowa tu
+o&nbsp;fontach zapisanych w&nbsp;formacie Adobe Type&nbsp;1 -- zawarty
+jest w&nbsp;pliku z&nbsp;rozszerzeniem <code>.pfb</code> (<em>
+PostScript Font Binary</em>) lub <code>.pfa</code> (<em> PostScript
+Font ASCII</em>). Natomiast o&nbsp;plikach <code>TFM</code>
+w&nbsp;świecie PostScript-owym mało kto słyszał. Na szczęście dobrzy
+ludzie z&nbsp;firmy Adobe wymyślili coś podobnego do tego, co wymyślił
+Donald E.&nbsp;Knuth, mianowicie pliki metryczne AFM (<em>Adobe Font
+Metric</em>). Różnią się one trochę od plików <code>TFM</code>
+(np.&nbsp;pliki <code>AFM</code> są plikami tekstowymi), ale mimo
+różnic jest możliwe by na podstawie pliku <code>AFM</code> utworzyć
+plik <code>TFM</code>.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Znaki"><h2>Reprezentacja znaków</h2>
+<P>
+Zanim pójdziemy dalej trzeba wyjaśnić jedną rzecz, mianowicie
+w&nbsp;jaki sposób są reprezentowane znaki. Jeżeli chodzi o&nbsp;plik
+<code>DVI</code> to odpowiedź jest trywialna: jako liczby
+z&nbsp;zakresu <code>0</code>--<code>255</code>. Przy tworzeniu pliku
+PostScript-owego za pomocą sterownika sytuacja <em> nie ulega</em>
+zmianie, to znaczy w&nbsp;pliku PostScript-owym znaki też są
+reprezentowane w&nbsp;zasadzie jako liczby z&nbsp;zakresu
+<code>0</code>--<code>255</code>, czasem w&nbsp;reprezentacji ASCII,
+a&nbsp;czasem w&nbsp;reprezentacji ósemkowej. Natomiast we
+,,właściwym foncie'' PostScript-owym, podobnie zresztą jak
+w&nbsp;foncie METAFONT-owym, jest inaczej: znaki są zasadniczo
+reprezentowane za pomocą nazw w&nbsp;rodzaju ,,period'',
+,,periodcentered'', ,,lslash'', ,,aogonek'',&nbsp;itp.
+</P>
+<P>
+Formalnie rzecz biorąc font PostScript-owy jest programem,
+a&nbsp;nazwy znaków są nazwami podprogramów opisujących kształt znaków
+za pomocą -- znów podobnie jak w&nbsp;programach METAFONT-owych --
+krzywych trzeciego stopnia, zwanych krzywymi B&eacute;ziera. Dodatkowo
+podprogramy te opisują niektóre szczegóły procesu zamiany obwiedni na
+mapy bitowe (tzw.&nbsp;<em> hinty</em> 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ą.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Nazwy-i-kody"><h2>Nazwy i kody znaków</h2>
+
+Skąd zatem PostScript trafiając na jakąś liczbę ,,wie'', że ma użyć
+procedury o&nbsp;nazwie, powiedzmy, ,,aogonek''?
+</P>
+<P>
+Aaa, właśnie! Tu jest pies pogrzebany. We ,,właściwym foncie''
+PostScript-owym jest zawarta dodatkowa informacja, mianowicie tabela
+par (liczba,&nbsp;nazwa) przyporządkowująca liczbom z&nbsp;zakresu
+<code>0</code>--<code>255</code> 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&nbsp;locie'' zmienić. Z&nbsp;tej możliwości korzysta m.in.
+sterownik <code>DVIPS</code> (p.&nbsp;niżej).
+</P>
+
+<!-- ............................................................... -->
+<A NAME=AFMTFM><h2>Konwersja AFM -> TFM</h2>
+<P>
+W&nbsp;pliku AFM znajduje się również informacja
+o&nbsp;przyporządkowaniu liczba-nazwa, (w&nbsp;zasadzie można
+zakładać, że jest to to samo przyporządkowanie, co w&nbsp;pliku
+<code>PFB</code>/<code>PFA</code>). Na ogół nie jest to
+przyporządkowanie, o&nbsp;które by nam chodziło. Ale nie ma biedy --
+<code>DVIPS</code>-owi można podać <em> dowolne</em>
+przyporządkowanie, które zostanie użyte w&nbsp;tworzonym przezeń pliku
+PostScript-owym.
+</P>
+<P>
+Konwertery <code>AFM->TFM</code> na podstawie nazw generują stosowne
+przyporządkowanie, lub nawet wiele przyporządkowań, a&nbsp;dla każdego
+z&nbsp;takich przyporządkowań tworzony jest odpowiadający mu
+plik&nbsp;<code>TFM</code>.
+</P>
+<P>
+Najpowszechniej używanym konwerterem jest program
+<code>AFM2TFM</code>, należący do standardowej dystrybucji sterownika
+<code>DVIPS</code>. Konwerter o&nbsp;nazwie <A
+HREF="ftp://ftp.GUST.org.pl/pub/TeX/fonts/utilities/t1install/toil/">TOIL</A>,
+bazuje na programach <code>AWK</code> oraz METAFONT Warto też
+wspomnieć o&nbsp;pakiecie <code>VFINST</code>, oferującym liczne
+możliwości, bazującym na fontach wirtualnych.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME=AFMTFMp><h2>Konwersja AFM -> TFM -- poprawność nazw znaków</h2>
+<P>
+Aby konwertery <code>AFM->TFM</code> mogły działać jak należy, nazwy
+podprogramów muszą być zgodne z&nbsp;ich treścią. Tak niestety nie
+zawsze jest, np.&nbsp;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.&nbsp;standardów
+kodowania znaków, czyli <em>infinity</em>.
+</P>
+<P>
+Z&nbsp;niepoprawnymi nazwami można sobie poradzić. Co nam zależy,
+przecież ,,onesuperior'' brzmi równie ładnie jak ,,aogonek'',
+nieprawdaż? Problem jedynie w&nbsp;tym, że z&nbsp;góry nie wiadomo, że
+producent uznał ,,onesuperior'' za odpowiednią nazwę dla polskiej
+litery ,,ą''. We&nbsp;wspomnianych fontach firmy ThETA (p.&nbsp;niżej)
+akurat tak jest, ale tak bynajmniej być nie musi, w&nbsp;końcu jakiś
+szaleniec może się pogodzić z&nbsp;propozycją Adobe i&nbsp;użyć dla
+podprogramu opisującego ,,ą'' nazwy ,,agonek''...
+</P>
+<P>
+Jakby nie dość było problemów, oprócz nazewnictwa ewidentnie
+niepoprawnego możemy się zetknąć z&nbsp;obocznością! Otóż niektórzy
+producenci dla określenia znaków ,,ż'' i&nbsp;,,Ż'' używają nazw
+,,zdot'' i&nbsp;,,Zdot'', a&nbsp;niektórzy ,,zdotaccent''
+i&nbsp;,,Zdotaccent''. Nie znalazłem jednoznacznego stanowiska firmy
+Adobe w&nbsp;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&nbsp;,,Zdotaccent'', ale
+być może konwertery <code>AFM->TFM</code> powinny być uwrażliwione na
+tę oboczność.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME=AFMTFMk><h2>Konwersja AFM -> TFM -- kerny i&nbsp;ligatury</h2>
+<P>
+Plik <code>TFM</code> zawiera jeszcze informację o&nbsp;parach
+kernowych i&nbsp;ligaturach. Pary kernowe, uwzględniane ,,jak leci''
+przez większość konwerterów <code>AFM->TFM</code>, na ogół są
+umieszczane jak należy w&nbsp;plikach <code>AFM</code>, chociaż
+czasami można trafić na felerne pliki <code>AFM</code> 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 <code>AFM</code> posiadające tylko część par
+kernowych -- np.&nbsp;znaki diakrytyczne czasami nie są uwzględniane
+-- dobrze jest sprawdzić plik <code>AFM</code> pod tym kątem.
+</P>
+<P>
+Z&nbsp;ligaturami jest znacznie gorzej -- można je bardzo rzadko
+uświadczyć, mimo iż teoretycznie format <code>AFM</code> pozwala na
+definiowanie ligatur, np.&nbsp;poniższy przykładowy wiersz pliku
+<code>AFM</code>:
+<pre>
+C 45; WX 329; N hyphen; B 17 188 313 303; L hyphen endash;
+</pre>
+zgodnie ze specyfikacją Adobe ustala, że znak o&nbsp;kodzie
+<code>45</code> ma szerokość <code>329</code> jednostek (jednostka =
+1/1000em), nosi nazwę ,,hyphen'', że naroża prostokąta ograniczającego
+obrys znaku mają współrzędne wynoszące w&nbsp;tych samych jednostkach
+(17, 188) oraz (313, 303), i&nbsp;wreszcie że dwa znaki ,,hyphen''
+mają być zamieniane na znak o&nbsp;nazwie ,,endash'', czyli innymi
+słowy znak o&nbsp;nazwie ,,endash'' jest ligaturą dwóch znaków
+o&nbsp;nazwie ,,hyphen''.
+</P>
+<P>
+W&nbsp;związku z&nbsp;powszechnym brakiem informacji o&nbsp;ligaturach
+w&nbsp;plikach <code>AFM</code>, konwertery <code>AFM->TFM</code>
+muszą albo się domyślić, jakie by tu ligatury można wstawić, albo --
+co chyba jest lepszym rozwiązaniem -- zostać poinformowane
+o&nbsp;prawidłowych dla danego fontu (grupy fontów) ligaturach.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME=Pliki-cnf><h2>Pliki konfiguracyjne sterownika <code>DVIPS</code></h2>
+<P>
+Popularny sterownik <code>DVIPS</code>, autorstwa Tomasa Rokickiego,
+zamieniający pliki <code>DVI</code> na pliki PostScript-owe musi
+wiedzieć -- podobnie jak każdy sterownik -- gdzie znajdują się fonty
+TeX-owe i&nbsp;PostScript-owe. Informację tę zawierają pliki
+<code>config.ps</code> i&nbsp;<code>psfonts.map</code>, poszukiwane
+w&nbsp;kartotekach wskazywanych przez zmienną systemową
+<code>TEXCONFIG</code> (we współczesnych instalacjach zmienna ta
+jest już zwykle zadeklarowana w&nbsp;pliku konfiguracyjnym
+<code>texmf.cnf</code>).
+</P>
+<P>
+Plik <code>config.ps</code> zawiera informację o&nbsp;lokalizacji
+plików <code>TFM</code>, plików <code>PK</code>, fontów wirtualnych,
+oraz fontów PostScript-owych. Natomiast plik <code>psfonts.map</code>
+zawiera informacje związane wyłącznie dostępnymi w&nbsp;danej
+instalacji fontami PostScript-owymi. W&nbsp;pliku
+<code>psfonts.map</code> informacje o&nbsp;poszczególnych fontach
+umieszczane są w&nbsp;jednym wierszu (co czasem może być kłopotliwe).
+Typowy wiersz wygląda następująco:
+<pre>
+qplr QuasiPalladio-Regular "enc-qpl ReEncodeFont" &lt;qpl.enc &lt;qplr.pfb
+</pre>
+Pierwsza pozycja określa nazwę TeX-ową fontu, druga -- wewnętrzną
+nazwę PostScript-ową fontu (robi z&nbsp;niej użytek interpreter
+PostScript-u), następnie pojawia się informacja o&nbsp;dodatkowych
+zabiegach, jakim ma być poddany font (może to być poziome
+przeskalowanie fontu, pochylenie lub zmiana kodowania -- w&nbsp;tym
+przypadku chodzi o&nbsp;zmianę kodowania), a&nbsp;na końcu pojawiają
+się nazwy plików, które mają zostać dołączone do dokumentu TeX-owego
+-- w&nbsp;tym wypadku jest to plik kodowania <code>qpl.enc</code> oraz
+font <code>qplr.pfb</code>.
+</P>
+<P>
+Podanie nazwy pliku fontowego nie jest konieczne -- w&nbsp;takim
+wypadku <code>DVIPS</code> założy, że chodzi o&nbsp;font wbudowany
+w&nbsp;urządzenie. Gorąco odradzamy korzystanie z&nbsp;tej możliwości
+-- opłakane skutki korzystania z&nbsp;fontów wbudowanych można co
+jakiś czas oglądać w&nbsp;materiałach nawet renomowanych firm:
+a&nbsp;to zamiast polskich znaków występują ,,krzaczki'', a&nbsp;to
+litery zachodzą na siebie, a&nbsp;to skład się zupełnie rozjeżdża...
+</P>
+<P>
+Plik kodowania zawiera tablicę 256 nazw znaków, określającą omawiane
+wyżej przyporządkowanie kod-nazwa. Jest to w&nbsp;istocie fragment
+kodu PostScript-owego postaci:
+<pre>
+/enc-qpl[
+ /.notdef
+ /Delta
+ /beta
+ ...
+ /thorn
+ /quotedblbase
+ ] def
+</pre>
+O&nbsp;tym, jaki kod otrzymuje dany znak, decyduje kolejność
+wystąpienia: w&nbsp;tym przypadku na pozycji zerowej (w&nbsp;języku
+PostScript liczenie zawsze odbywa się od zera) występuje znak
+o&nbsp;nazwie <code>.notdef</code> (znak ,,ciach'' <code>/</code>
+w&nbsp;notacji PostScript-owej oznacza mniej więcej to samo co znak
+,,w-tył-ciach'' <code>\</code> w&nbsp;notacji TeX-owej), co oznacza,
+że w&nbsp;foncie w&nbsp;istocie nie ma znaku o&nbsp;tym kodzie; znak
+<code>Delta</code> otrzymuje kod&nbsp;1, znak <code>beta</code> --
+kod&nbsp;2, ..., znak <code>thorn</code> -- kod&nbsp;254,
+i&nbsp;wreszcie znak <code>quotedblbase</code> -- kod&nbsp;255.
+</P>
+<P>
+Warto mieć świadomość, że <code>DVIPS</code> włącza wszelkie pliki
+prawie ich nie analizując, jedyny zabieg przezeń wykonywany to zamiana
+postaci binarnej fontu Type&nbsp;1 (<code>PFB</code>) na postać ASCII
+(<code>PFA</code>). Jeżeli font jest już w&nbsp;postaci ASCII, to
+włączany jest do dokumentu ,,jak leci'', bez żadnej ingerencji ze
+strony sterownika. Oznacza to, że używając <code>DVIPS</code>-a możemy
+korzystać ze wszystkich możliwych fontów PostScript-owych, nie tylko
+najbardziej popularnych fontów Type&nbsp;1, ale w&nbsp;szczególności
+także fontów TrueType, które dla interpretera PostScript-u są po
+prostu fontami Type&nbsp;42 -- wystarczy mieć plik <code>TFM</code>
+i&nbsp;font&nbsp;Type&nbsp;42 w&nbsp;postaci ASCII.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Latanie"><h2>Łatanie fontów -- niepoprawny font</h2>
+<P>
+Używając różnych wymyślnych narzędzi (np.&nbsp;<A
+HREF="ftp://ftp.GUST.org.pl/TeX/fonts/utilities/t1utils/">T1UTIL</A>
+Lee Hetheringtona) można
+się zorientować, jakim znakom zostały przypisane jakie nazwy
+i&nbsp;w&nbsp;razie czego je poprawić, można też uzupełniać kerny,
+itp., ale to jest żmudne i&nbsp;przykre, bo niepotrzebne zajęcie.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="BrakAFM"><h2>Łatanie fontów -- brak plików AFM</h2>
+<P>
+Czasem fonty PostScript-owe są dystrubuowane z&nbsp;plikami
+<code>PFM</code> (<em>Printer Font Metric</em>) zamiast z&nbsp;plikami
+AFM.
+</P>
+<P>
+Brak plików <code>AFM</code> <em> praktycznie przekreśla</em>
+możliwość użycia fontu PostScript-owego w&nbsp;TeX-u, bowiem pliki
+<code>PFM</code> zawierają znacznie uboższą informację niż pliki AFM,
+w&nbsp;szczególności <em> nie zawierają</em> nazw znaków, czyli nie
+określają żadnej tablicy kodowania (<em> encoding vector</em>,
+p.&nbsp;wyżej). Można zakładać, że chodzi o&nbsp;takie samo
+przyporządkowanie, jakie jest wpisane w&nbsp;pliku
+<code>PFB</code>/<code>PFA</code>, chociaż w&nbsp;ogólności tak być
+nie musi. Ponadto w&nbsp;pliku <code>PFM</code> znajdują się dane na
+temat par kernowych jedynie dla co najwyżej 256 znaków, a&nbsp;font
+PostScript-owy może ich zawierać nacznie więcej.
+</P>
+<P>
+Jeśli jednak szczęście nam dopisze, to z&nbsp;plików <code>PFM</code>
+oraz <code>PFB</code> (bądź <code>PFA</code>) możemy odtworzyć
+informację niezbędną do utworzenia pliku <code>AFM</code> -- można
+spróbować użyć pakietu
+<A HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/pf2afm.zip">pf2afm</A>,
+który niedawno pojawił się
+w&nbsp;archiwum GUST-u.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="ThETA"><h2>Casus ThETA</h2>
+<P>
+Ostatnio na rynku Polskim pojawiły się godne uwagi polonizacje fontów
+firmy BitStream, sygnowane przez firmę ThETA.
+</P>
+<P>
+Niestety firma ThETA wyraźnie zignorowała rynek TeX-owy, chociaż może
+i&nbsp;słusznie zignorowała, skoro TeX-owców jakoś nie widać
+i&nbsp;nie słychać, no może z&nbsp;wyjątkiem kilkorga spośród 150
+niegroźnych wariatów zapisanych do GUST-u...
+</P>
+<P>
+Otóż firma ThETA wydała jak do tej pory 3&nbsp;płyty CD z&nbsp;fontami, każda
+kolejna płyta zawierała inne fonty i&nbsp;była coraz mniej przydatna dla
+TeX-owców:
+</P>
+
+<ul>
+<li> Pierwsza płyta (cena ok.&nbsp;500&nbsp;zł) miała nazwy znaków
+w&nbsp;zasadzie poprawne z&nbsp;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
+<code>TFM</code> przebiegało bezboleśnie i&nbsp;ż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.
+
+<li> Niepoprawność formalna polegała na braku w&nbsp;tych fontach
+<em>wymaganego</em> przez dokumentację Adobe podprogramu (znaku)
+o&nbsp;egzotycznej nazwie ,,.notdef''. (Podprogram ten jest używany,
+gdy z&nbsp;jakichś powodów program PostScript-owy odwołuje się do
+znaku, którego nie ma w&nbsp;foncie; w&nbsp;większości fontów jest to
+znak nie zawierający żadnego elementu graficznego, odpowiadający
+w&nbsp;zasadzie spacji.)
+
+<li> Było też drugie wydanie pierwszej płyty, ,,poprawione''
+w&nbsp;duchu opisanej niżej drugiej płyty.
+
+<li> Z&nbsp;drugą płytą (cena ok.&nbsp;450&nbsp;zł) było lepiej jeżeli
+chodzi o&nbsp;znak ,,.notdef'', natomiast gorzej, jeśli chodzi
+o&nbsp;nazwy znaków. Oto errata:
+</P>
+
+<table frame=1 width=80% align=center>
+<tr bgcolor=yellow><td> JEST </td><td>WINNO BYĆ </td></tr>
+<tr><td> ordmasculine </td><td> ae </td></tr>
+<tr bgcolor=yellow><td> ordfeminine </td><td> AE </td></tr>
+<tr><td> tilde </td><td> ecircumflex </td></tr>
+<tr bgcolor=yellow><td> circumflex </td><td> Ecircumflex </td></tr>
+<tr><td> onequarter </td><td> ntilde </td></tr>
+<tr bgcolor=yellow><td> logicalnot </td><td> Ntilde </td></tr>
+<tr><td> c157 </td><td> oe </td></tr>
+<tr bgcolor=yellow><td> c141 </td><td> OE </td></tr>
+<tr><td> cent </td><td> questiondown </td></tr>
+<tr bgcolor=yellow><td> florin </td><td> Ydieresis </td></tr>
+<tr><td> c142 </td><td> Zcaron </td></tr>
+<tr bgcolor=yellow><td> c158 </td><td> zcaron </td></tr>
+<tr><td> onesuperior </td><td> aogonek </td></tr>
+<tr bgcolor=yellow><td> yen </td><td> Aogonek </td></tr>
+<tr><td> ae </td><td> cacute </td></tr>
+<tr bgcolor=yellow><td> AE </td><td> Cacute </td></tr>
+<tr><td> ecircumflex </td><td> eogonek </td></tr>
+<tr bgcolor=yellow><td> Ecircumflex </td><td> Eogonek </td></tr>
+<tr><td> threesuperior </td><td> lslash </td></tr>
+<tr bgcolor=yellow><td> sterling </td><td> Lslash </td></tr>
+<tr><td> ntilde </td><td> nacute </td></tr>
+<tr bgcolor=yellow><td> Ntilde </td><td> Nacute </td></tr>
+<tr><td> oe </td><td> sacute </td></tr>
+<tr bgcolor=yellow><td> OE </td><td> Sacute </td></tr>
+<tr><td> questiondown </td><td> zdotaccent </td></tr>
+<tr bgcolor=yellow><td> macron </td><td> Zdotaccent </td></tr>
+<tr><td> Ydieresis </td><td> zacute </td></tr>
+<tr bgcolor=yellow><td> c143 </td><td> Zacute </td></tr>
+</table>
+</P>
+
+<li> Indagowany na tę okoliczność autor polonizacji Jakub Tatarkiewicz
+stwierdził, że tak jest dobrze, i&nbsp;że nie będzie dla paru zapaleńców
+przygotowywał specjalnej ,,TeX-owej'' (czyt.:&nbsp;poprawnej) wersji.
+
+<li> Z&nbsp;trzecią płytą (cena ok.&nbsp;300&nbsp;zł) jest
+zdecydowanie najgorzej, bo firma ThETA wyposażyła je jedynie w&nbsp;pliki
+<code>PFM</code>.
+</ul>
+
+Na szczęście dla TeX-owców ,,podłatanie'' fontów ThETA nie jest
+trudne. W&nbsp;archiwum GUST-u znajduje się pakiet <A
+HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/thetafix102.zip">THETAFIX</A>,
+korzystający ze wspomnianych programów Lee
+Hetheringtona oraz programu <code>AWK</code> (w&nbsp;wersji Gnu),
+dokonujący stosownych zmian w&nbsp;plikach składających się na fonty
+PostScript-owe z&nbsp;dwóch pierwszych płyt. Trzecią płytę można
+podłatać za pomocą wspomnianego pakietu&nbsp;<A
+HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/pf2afm.zip">pf2afm</A>.
+</P>
+<P>
+Po takich poprawkach i&nbsp;utworzeniu plików <code>TFM</code>
+większość fontów powinna się dać bez kłopotów używać
+w&nbsp;dokumentach TeX-owych. Niestety większość, a&nbsp;nie
+wszystkie, bowiem kilkaset fontów z&nbsp;pierwszych dwóch płyt można
+pogrupować w&nbsp;kilkadziesiąt różnych klas, w&nbsp;zależności od
+zestawu znaków. Pakiet <A
+HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/thetafix102.zip">THETAFIX</A>
+jest przystosowany do
+jednej z&nbsp;klas, tej najbardziej licznej. Ale w&nbsp;złośliwych
+przypadkach coś może nie zadziałać -- kłopoty są ceną, jaką się płaci
+za tanie fonty... Tak, tak, 1000&nbsp;zł za kilkaset fontów to
+stosunkowo tanio.
+</P>
+
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+<!-- ................................................................. -->
+<A NAME="Podsumowanie"><h2>Podsumowanie</h2>
+<P>
+Warto pamiętać, że font nie tylko musi ładnie w&nbsp;druku wyglądać,
+ale i&nbsp;jego dość skomplikowana ,,wewnętrzna'' struktura musi być
+zrobiona porządnie.
+</P>
+<P>
+Jednym z&nbsp;najbardziej dających się we znaki problemów jest problem
+układu znaków w&nbsp;foncie. Staranne przemyślenie tego problemu <em>
+musi</em> prowadzić do wniosku, że firma Adobe już dawno temu znalazła
+<em> wystarczające</em> w&nbsp;większości przypadków rozwiązanie
+problemu konfigurowalności układu znaków w&nbsp;foncie. To bardzo
+mocny argument na rzecz korzystania z&nbsp;fontów PostScript-owych
+w&nbsp;formacie Type&nbsp;1.
+</P>
+<P>
+Wprawdzie detale związane z&nbsp;instalowaniem fontów mogą się wydawać
+skomplikowane, ale taka jest natura rzeczy. A&nbsp;do czego prowadzi
+próba ukrycia tej natury przed użytkownikiem, wielu z&nbsp;nas
+boleśnie odczuło w&nbsp;przypadku korzystania fontów TrueType
+w&nbsp;systemie Windows. Wprawdzie instaluje się je bardzo prosto
+(albo i&nbsp;-- nie wiedzieć czemu -- nie instaluje), ale praktycznie
+nie ma <em> żadnej</em> możliwości rekonfiguracji. Ktoś, kto
+przenosił fonty TrueType z&nbsp;jednej wersji systemu Windows do
+innej, wie o&nbsp;czym mowa -- a&nbsp;to font się w&nbsp;ogóle nie
+daje zainstalować, a&nbsp;to inne znaki się pojawiają, niż byśmy
+chcieli, a&nbsp;to nasza ulubiona aplikacja albo tego fontu nie widzi,
+albo się na nim wywraca...
+</P>
+<P>
+Mając to na względzie uważamy, że warto poświęcić nieco czasu
+i&nbsp;wysiłku na zrozumienie podstaw konfigurowania fontów, zwłaszcza
+fontów PostScript-owych w&nbsp;formacie Adobe Type&nbsp;1 -- to
+naprawdę w&nbsp;pewnym momencie staje się proste, a&nbsp;tym samym
+oczywiście niezwykle użyteczne.
+</P>
+<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P>
+
+Bogusław Jackowski i&nbsp;Staszek Wawrykiewicz
+<P><i> Tekst jest przedrukiem z&nbsp;Biuletynu GUST, nr&nbsp;8/1997,
+s.&nbsp;7--12.</i><BR> <i>Ostatnia modyfikacja 14.04.2003</i>
+</P>
+</body>