mkfontdir i ttmkfdir - encodings.dir

Jakub Bogusz qboosh w pld.org.pl
Czw, 30 Maj 2002, 22:20:56 CEST


Udało mi się doprowadzić ttmkfdir2 do takiego stanu[1], że generowany
plik dla fontów TTF z XFree86 4.2.0 zawiera wszystkie wpisy jakie są
w pliku dostarczanym z tymi fontami (plus jeszcze dla paru innych
kodowań). Z innymi fontami TTF pliki fonts.scale w ogóle nie przychodzą
więc i tak je trzeba generować (i nie ma z czym porównać jakości), więc
IMO można przejść na generowanie /usr/share/fonts/TTF/fonts.scale przy
pomocy ttmkfdir zamiast składania z plików dostarczanych z fontami.

Problem jest z kodowaniami - ttmkfdir2 wewnętrznie zawiera ich tylko
część, a resztę może doczytać z plików *.enc - ale w tym celu trzeba mu
dać encondings.dir. Plik ten musi być albo w bieżącym katalogu, albo
w katalogu wskazanym przez opcję -e (czyli np. "ttmkfdir -e
/usr/share/fonts/encondings/encodings.dir"). Same kodowania są
w pakiecie XFree86-fonts[2], więc jego obecność jest potrzebna do
wygenerowania fonts.scale z pełną listą kodowań.

No i pytanie - dostarczać kopię encodings.dir w /usr/share/fonts/TTF,
czy dodawać ten parametr ze stałą ścieżką do wywołań ttmkfdir?
Jest jeszcze trzecie rozwiązanie: przerobić ttmkfdir, aby używał pliku
encodings.dir z /usr/share... zamiast w bieżącym katalogu - albo tylko
w przypadku nie znalezienia encodings.dir w bieżącym katalogu. Przy czym
odpowiedź na to pytanie może być zależna od tego, co robi mkfontdir
z plikami encodings.dir (jako że mkfontdir generuje fonts.dir
z fonts.scale - po prostu kopiując, ale to inna sprawa).

Odnośnie mkfontdir - oprócz fonts.dir usiłuje on generować także
encodings.dir - ale robi to na podstawie podanych katalogów z plikami
*.enc (w naszym przypadku powinno to być: -e /usr/share/fonts/encodings
-e /usr/share/fonts/encodings/large). Problem w tym, że w przypadku nie
podania tych katalogów mkfontdir _kasuje_ plik ./encodings.dir.
Nasze pakiety XFree86-fonts-{75dpi,100dpi} (i tylko te dwa) zawierają
kopię encodings.dir. Efekt jest taki, że wystarczy zainstalować te
pakiety, a rpm -V już znajduje błędy (brakujące pliki).

I znowu pytanie co z tym zrobić - nie generować encodings.dir
w katalogach z fontami, generować przez podawanie zawsze 2 stałych
ścieżek do mkfontdir, czy przekonać mkfontdir do szukania kodowań
w stałych miejscach, jeżeli nie poda mu się -e?


W rawhide pierwsze jest nierozwiązane (ttmkfdir generuje fonts.scale
z niepełną listą kodowań), drugie w sytuacji przejściowej (wywołania
mkfontdir z parametrami -e są zakomentowane, wg komentarzy encodings.dir
w ogóle mają być wywalone z katalogów z fontami).


[1] ponadto nie segfaultuje przy czytaniu kodowań - ten wzięty z rawhide
tak robił; tam rozwiązali to... wycinając część informacje z plików
*.enc (konkretnie linię FIRSTINDEX).

[2] tylko microsoft-win3.1.enc gdzieś wcięło, mimo że jest wymieniony
w encodings.dir i jest w X420src-2.tgz.

-- 
Jakub Bogusz    http://prioris.mini.pw.edu.pl/~qboosh/



Więcej informacji o liście dyskusyjnej pld-devel-pl