diff options
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.html | 671 |
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 jednej strony o dużym zainteresowaniu sprawami fontowymi, +a z drugiej strony -- o częstym niezrozumieniu podstawowych +spraw związanych z 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ę 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 świecie fontów. (Dodatkowe informacje na temat +wykorzystania fontów w LaTeX2e można znaleźć w dokumentacji +<A HREF="nfss.html">Fonty w 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 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 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 <code>TFM</code> (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 +(<em>italic correction</em> 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 <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 ogóle ,,prze-TeX-ować'' dokument potrzebne +są pliki <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 konwencją przyjętą przez Donalda E. Knutha nazwy +fontów rodziny Computer Modern zawierają formalny rozmiar fontu +w punktach, np. <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> <code>at</code> <code>12pt</code> -- +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, +<code>EC</code>, <code>PL</code>), a także fonty rodziny +<code>Euler</code>, fonty cyryliczne, i inne fonty tworzone +w 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 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. +</P> +<P> +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 +<code>Computer</code> <code>Modern</code>. Font calowy +<code>cminch</code>, przeznaczony do nagłówków, jest w istocie +przeskalowanym proporcjonalnie fontem <code>cmssbx10</code>. Innymi +słowy dokładnie ten sam efekt uzyskałoby się za pomocą instrukcji +<code>\font</code> <code>\f</code> +<code>cminch</code> <code>\f</code> i za pomocą instrukcji +<code>\font</code> <code>\f</code> +<code>cmssbx10</code> <code>at</code> <code>1.44in</code> <code>\f</code>. +Jedyna różnica polega na tym, że font <code>cminch</code> jest nieco +,,oszczędniejszy'' -- zawiera tylko duże litery i cyfry. +</P> +<P> +Sporo zamieszania wywołały także <code>plain</code>-owe instrukcje +<code>\magstephalf</code> i <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. <em> The TeX book</em>, +str. 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 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 +<pre> +\font... at ... +</pre> +jest w 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 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 nieco oszczędniejszy +format <code>PK</code> (<em>packed</em>). Do zamiany służy +program <code>GFTOPK</code>, z reguły wywoływany automatycznie +w procesie generowania fontów. +</P> +<P> +Fonty bitmapowe generowane są dla <em>konkretnej wielkości pisma +i konkretnego urządzenia</em>, 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. +</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 ś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. +</P> +<P> +Fonty <code>PK</code> 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 (<em> dots per inch</em>) powiększone +o 20% (<code>\magstep1</code>) znajdą się w katalogu +o 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 nazwę pliku, +np. <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 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 <code>PK</code>, 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 <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 <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 PostScript, to ten ,,właściwy font'' -- mowa tu +o fontach zapisanych w formacie Adobe Type 1 -- zawarty +jest w pliku z rozszerzeniem <code>.pfb</code> (<em> +PostScript Font Binary</em>) lub <code>.pfa</code> (<em> PostScript +Font ASCII</em>). Natomiast o plikach <code>TFM</code> +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 (<em>Adobe Font +Metric</em>). Różnią się one trochę od plików <code>TFM</code> +(np. 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 jaki sposób są reprezentowane znaki. Jeżeli chodzi o plik +<code>DVI</code> to odpowiedź jest trywialna: jako liczby +z zakresu <code>0</code>--<code>255</code>. Przy tworzeniu pliku +PostScript-owego za pomocą sterownika sytuacja <em> nie ulega</em> +zmianie, to znaczy w pliku PostScript-owym znaki też są +reprezentowane w zasadzie jako liczby z zakresu +<code>0</code>--<code>255</code>, 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. +</P> +<P> +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. <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 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, nazwa) przyporządkowująca liczbom z 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 locie'' zmienić. Z tej możliwości korzysta m.in. +sterownik <code>DVIPS</code> (p. niżej). +</P> + +<!-- ............................................................... --> +<A NAME=AFMTFM><h2>Konwersja AFM -> TFM</h2> +<P> +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 +<code>PFB</code>/<code>PFA</code>). Na ogół nie jest to +przyporządkowanie, o 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 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 dla każdego +z takich przyporządkowań tworzony jest odpowiadający mu +plik <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 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 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 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 <em>infinity</em>. +</P> +<P> +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 ,,agonek''... +</P> +<P> +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 <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 ligatury</h2> +<P> +Plik <code>TFM</code> zawiera jeszcze informację o parach +kernowych i ligaturach. Pary kernowe, uwzględniane ,,jak leci'' +przez większość konwerterów <code>AFM->TFM</code>, na ogół są +umieszczane jak należy w 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. znaki diakrytyczne czasami nie są uwzględniane +-- dobrze jest sprawdzić plik <code>AFM</code> pod tym kątem. +</P> +<P> +Z ligaturami jest znacznie gorzej -- można je bardzo rzadko +uświadczyć, mimo iż teoretycznie format <code>AFM</code> pozwala na +definiowanie ligatur, np. 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 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 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''. +</P> +<P> +W związku z powszechnym brakiem informacji o ligaturach +w 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 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 PostScript-owe. Informację tę zawierają pliki +<code>config.ps</code> i <code>psfonts.map</code>, poszukiwane +w kartotekach wskazywanych przez zmienną systemową +<code>TEXCONFIG</code> (we współczesnych instalacjach zmienna ta +jest już zwykle zadeklarowana w pliku konfiguracyjnym +<code>texmf.cnf</code>). +</P> +<P> +Plik <code>config.ps</code> zawiera informację o 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 danej +instalacji fontami PostScript-owymi. W pliku +<code>psfonts.map</code> informacje o poszczególnych fontach +umieszczane są w jednym wierszu (co czasem może być kłopotliwe). +Typowy wiersz wygląda następująco: +<pre> +qplr QuasiPalladio-Regular "enc-qpl ReEncodeFont" <qpl.enc <qplr.pfb +</pre> +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 tym +przypadku chodzi o zmianę kodowania), a na końcu pojawiają +się nazwy plików, które mają zostać dołączone do dokumentu TeX-owego +-- w 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 takim +wypadku <code>DVIPS</code> 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... +</P> +<P> +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: +<pre> +/enc-qpl[ + /.notdef + /Delta + /beta + ... + /thorn + /quotedblbase + ] def +</pre> +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 <code>.notdef</code> (znak ,,ciach'' <code>/</code> +w notacji PostScript-owej oznacza mniej więcej to samo co znak +,,w-tył-ciach'' <code>\</code> w notacji TeX-owej), co oznacza, +że w foncie w istocie nie ma znaku o tym kodzie; znak +<code>Delta</code> otrzymuje kod 1, znak <code>beta</code> -- +kod 2, ..., znak <code>thorn</code> -- kod 254, +i wreszcie znak <code>quotedblbase</code> -- kod 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 1 (<code>PFB</code>) na postać ASCII +(<code>PFA</code>). 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 <code>DVIPS</code>-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 <code>TFM</code> +i font Type 42 w 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. <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 w razie czego je poprawić, można też uzupełniać kerny, +itp., ale to jest żmudne i 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 plikami +<code>PFM</code> (<em>Printer Font Metric</em>) zamiast z plikami +AFM. +</P> +<P> +Brak plików <code>AFM</code> <em> praktycznie przekreśla</em> +możliwość użycia fontu PostScript-owego w TeX-u, bowiem pliki +<code>PFM</code> zawierają znacznie uboższą informację niż pliki AFM, +w szczególności <em> nie zawierają</em> nazw znaków, czyli nie +określają żadnej tablicy kodowania (<em> encoding vector</em>, +p. wyżej). Można zakładać, że chodzi o takie samo +przyporządkowanie, jakie jest wpisane w pliku +<code>PFB</code>/<code>PFA</code>, chociaż w ogólności tak być +nie musi. Ponadto w pliku <code>PFM</code> 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. +</P> +<P> +Jeśli jednak szczęście nam dopisze, to z 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 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 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... +</P> +<P> +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: +</P> + +<ul> +<li> 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 +<code>TFM</code> 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. + +<li> Niepoprawność formalna polegała na braku w tych fontach +<em>wymaganego</em> 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.) + +<li> Było też drugie wydanie pierwszej płyty, ,,poprawione'' +w duchu opisanej niżej drugiej płyty. + +<li> 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: +</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 że nie będzie dla paru zapaleńców +przygotowywał specjalnej ,,TeX-owej'' (czyt.: poprawnej) wersji. + +<li> Z trzecią płytą (cena ok. 300 zł) jest +zdecydowanie najgorzej, bo firma ThETA wyposażyła je jedynie w pliki +<code>PFM</code>. +</ul> + +Na szczęście dla TeX-owców ,,podłatanie'' fontów ThETA nie jest +trudne. W 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 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 <A +HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/pf2afm.zip">pf2afm</A>. +</P> +<P> +Po takich poprawkach i utworzeniu plików <code>TFM</code> +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 <A +HREF="ftp://ftp.GUST.org.pl/pub/TeX/GUST/contrib/fonts/tools/thetafix102.zip">THETAFIX</A> +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. +</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 druku wyglądać, +ale i jego dość skomplikowana ,,wewnętrzna'' struktura musi być +zrobiona porządnie. +</P> +<P> +Jednym z najbardziej dających się we znaki problemów jest problem +układu znaków w 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 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. +</P> +<P> +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 <em> żadnej</em> 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... +</P> +<P> +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. +</P> +<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis treści</A></P> + +Bogusław Jackowski i Staszek Wawrykiewicz +<P><i> Tekst jest przedrukiem z Biuletynu GUST, nr 8/1997, +s. 7--12.</i><BR> <i>Ostatnia modyfikacja 14.04.2003</i> +</P> +</body> |