1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
|
<!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>
<!-- <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> -->
<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>).</p>
<!-- Spis tre¶ci ....................................................... -->
<hr /> <a id="P0" name="P0"></a>
<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="#Podsumowanie">Podsumowanie</a></li>
</ul>
<hr />
<!-- ................................................................. -->
<a id="Fonty-TFM" name="Fonty-TFM"></a>
<h2><a id="Fonty-TFM" name="Fonty-TFM">Fonty „TeX-owe” czyli pliki
TFM</a></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 id="Fonty-wlasciwe" name="Fonty-wlasciwe"></a>
<h2><a id="Fonty-wlasciwe" name="Fonty-wlasciwe">Fonty
„w³a¶ciwe”</a></h2>
<p>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>
<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis tre¶ci</A></P>
<!-- ................................................................. -->
<a id="Fonty-CM" name="Fonty-CM"></a>
<h2><a id="Fonty-CM" name="Fonty-CM">Fonty rodziny Computer
Modern</a></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</p>
<pre>
\font... at ...
</pre>
<p>jest w tym kontek¶cie godna polecenia.</p>
<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis tre¶ci</A></P>
<!-- ................................................................. -->
<a id="Fonty-bitmapowe" name="Fonty-bitmapowe"></a>
<h2><a id="Fonty-bitmapowe" name="Fonty-bitmapowe">Fonty
bitmapowe</a></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>
<p>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>mktexpk</code> (ró¿ne wersje
<code>Unix</code>, <code>Windows</code> i <code>Amiga</code>).</p>
<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis tre¶ci</A></P>
<!-- ................................................................. -->
<a id="Fonty-PS" name="Fonty-PS"></a>
<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 id="Znaki" name="Znaki"></a>
<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 id="Nazwy-i-kody" name="Nazwy-i-kody"></a>
<h2>Nazwy i kody znaków</h2>
<p>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 id="AFMTFM" name="AFMTFM"></a>
<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/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 id="AFMTFMp" name="AFMTFMp"></a>
<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 „±”.
Jaki¶
szaleniec mo¿e siê pogodziæ z propozycj± Adobe i u¿yæ dla
podprogramu opisuj±cego „±” nazwy „aogonek”…</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 id="AFMTFMk" name="AFMTFMk"></a>
<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>:</p>
<pre>
C 45; WX 329; N hyphen; B 17 188 313 303; L hyphen endash;
</pre>
<p>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 id="Pliki-cnf" name="Pliki-cnf"></a>
<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 informacje o parametrach
pracy programu.
<!-- 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 z 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:</p>
<pre>
ec-qplr TeXGyrePagella-Regular "encqec ReEncodeFont" <q-ec.enc <qplr.pfb
</pre>
<p>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 <code>q-ec.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:</p>
<pre>
/encqec[
/grave
/acute
/circumflex
...
/thorn
/germandbls
] def
</pre>
<p>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>grave</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),znak
<code>acute</code> otrzymuje kod 1, znak <code>circumflex</code> –
kod 2, …, znak <code>thorn</code> – kod 254,
i wreszcie znak <code>germandbls</code> – kod 255.
Wyst±pienie <code>.notdef</code> oznacza, ¿e
w foncie nie ma znaku na pozycji o danym kodzie.</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 id="Latanie" name="Latanie"></a>
<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 id="BrakAFM" name="BrakAFM"></a>
<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/GUST/contrib/fonts/tools/pf2afm.zip">
pf2afm</a>, który dostêpny jest w archiwum GUST-u.</p>
<P><A HREF=#P0><IMG ALIGN="BOTTOM" SRC="back.gif"> Spis tre¶ci</A></P>
<!-- ................................................................. -->
<a id="Podsumowanie" name="Podsumowanie"></a>
<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>Powy¿szy tekst jest zmodyfikowan± wersj± artyku³u
z Biuletynu GUST, nr 8/1997, s. 7–12.</i><br />
<i>Ostatnie zmiany 5.05.2014</i></p>
</P>
</body>
</html>
|
