🚀 go-pugleaf

Spróbuję podsumować dotychczasowe przemyślenia i wysłowić moją
wizję przedsięwzięcia, mając nadzieję, że moje wyobrażenia na temat
rzeczywistości są w dużej mierze z nią zgodne, a pomysły sensowne.

Dyskusja jest na pl.comp.sys.xwindow. Posyłam teraz jeszcze na
pl.comp.ogonki, żeby ewentualnie kogoś zachęcić do przyłączenia się
albo dania rad.

Cel: Żeby Linux miał porządne fonty.

Droga do tego celu składa się z kilku oddzielnych etapów.


1. Przygotowanie systemu do wyciśnięcia z dostępnych fontów więcej niż
   to sobie ich autorzy wyobrażali.

Ogólnie polega to na dostarczaniu wirtualnych fontów zbudowanych w locie
na podstawie tych fizycznie dostępnych, zmieniając różne charakterystyki
fontu. XFree już to częściowo robi - oprócz oczywistej sprawy rasteryzacji
w danych wielkościach fontów z natury skalowalnych, skaluje też fonty
bitmapowe, zarówno jeśli chodzi o interpretowanie danych bitmap jako inną
rozdzielczość w dpi, jak i fizycznie skalując bitmapy.

Podobnie można dostarczać fontów o innej wadze oraz fontów pochylonych
(umie to nawet Win31). Na razie jednak zajmiemy się zestawami znaków.
Programy chcą różnych ośmiobitowych zestawów albo Unikodu, fonty są
w różnych ośmiobitowych zestawach i w Unikodzie - czasem fizycznie we
fragmentach. Należałoby wziąć wszystkie dostępne fonty różniące się tylko
zestawem znaków, wrzucić ich znaki do wspólnego worka i wyciągać z tego
potrzebne zestawy. Można się dodatkowo pokusić o budowanie jakichś znaków,
których nie ma nigdzie.

Problemy, które mogą się pojawić:

a) Font może mieć niezgodny opis kodowania w nazwie z zawartością. Taki
   patent zastosowany do wszystkich fontów nie byłby wstecznie kompatybilny
   - zastosowany do niektórych istniejących fontów dałby co innego niż
   było dotychczas. Na przykład wypadną ramki ze znaków 1..31 w ISO-8859-x
   (dla xtermów), jeśli o nie nie zadbamy. Poza tym znaki są identyfikowane
   przez nazwy albo przez numery - chyba trudno z góry stwierdzić, które są
   w danym przypadku właściwe. Font może nawet wewnętrznie udawać ISO-8859-1,
   podczas gdy z nazwy i z wyglądu będzie to ISO-8859-2. A więc nie widzę
   pewnej metody rozpoznania znaków w foncie. Font może nawet mieć jakieś
   dzikie kodowanie nie przystające do Unikodu, więc nie zawsze zadziała
   wygodny sposób przekodowania wszystkiego wewnętrznie na Unikod i z powro­
   tem. Trzeba więc wiedzieć, które zestawy znaków konstruujemy, a które
   fonty pokazujemy bez zmian, przy możliwie prostej konfiguracji tego
   wszystkiego.

b) Nie wiem, czy technicznie się da mieszać fonty różnych rodzajów (np.
   bitmapowe z Type1). To zależy od interfejsu, którym programy dostają
   się do fontów, i etapu, na którym zachodzi rasteryzacja, na czym się
   nie znam.

c) W różnych zestawach znaków dla danego fontu mogą się pokrywać jakieś
   znaki (np. ASCII). Od czego ma zależeć, które są ważniejsze?

d) Czy jeśli brakuje jednego znaku z alfabetu serbskiego, to mamy pokazać,
   że oferujemy ten font w ISO-8859-5? Od czego to ma zależeć?

e) Trzeba jakoś nazywać arbitralne podzbiory Unikodu - najlepiej, żeby
   nawet fonty składające się na Unikod, nie przewidziane do samodzielnego
   używania, miały jednoznaczne nazwy - dla porządku i ogólności idei
   (coby źródłowe fonty mogły być teoretycznie czytane po nazwach, a nie
   bezpośrednio z plików).

f) Jak to zaimplementować? Kiedy rasteryzować font - przed połączeniem
   kawałków, po połączeniu ale przed wydzieleniem docelowego zestawu 
   (tutaj lepiej nie - za duży font wyjdzie), po wydzieleniu docelowego
   zestawu, po potrzebie dostępu do danego znaku?

Te problemy mogą spowodować, że zamiast robienia wszystkiego automatycznie,
trzeba będzie trzymać gdzieś i prowadzić ewidencję fontów poddawanych
obróbce pod tym względem. To dodatkowy kłopot dla użytkownika, że
zainstalowanie dodatkowych fontów wymaga ręcznego dopisania ich w jakimś
pliku konfiguracyjnym, jeśli chce z nich w pełni skorzystać. Chyba żeby
jakoś automatyzować tę konfigurację, pozostawiając tylko furtkę do
ręcznych ingerencji (przez trzymanie konfiguracji w pliku zamiast
generowania jej dynamicznie). Ewentualnie zamiast (albo oprócz) tego można
dać jakieś narzędzia, które dostosują konkretne fonty - np. ujednolicą
nazwy znaków z numerami i z nazwą fontu (z koniecznością ręcznego
poinformowania ich, co jest ważniejsze).

Dla uwspólniania danych egzotycznych podzbiorów Unikodu przez różne fonty
akurat nie jest konieczny ten plik konfiguracyjny - tutaj wystarczą aliasy.

Możliwe sposoby dostarczania znaków, których nie ma w fontach (opcjonalnie)
(część z tego można też przenieść na etap budowania fontów):

a) Zamiast niedostępnych znaków podsuwać podobne, na podstawie tablicy
   przybliżeń. Na przyład obcinać akcenty, a cyrylicę oddać w łacińskiej
   transliteracji.

b) Dorysowywać akcenty, na podstawie znaków zawierających same akcenty
   i bazy danych dostępnej na unicode.org zawierającej m.in. dekompozycje
   znaków na składowe i informacje o każdym akcencie, w jaki sposób jest
   dołączany do znaku.

c) Podsuwać ten znak z innego, możliwie podobnego fontu (w ten sposób
   jeśli jakiś font nie ma cyrylicy, to w dalszym ciągu w programie można
   go ustawić w opcjach dla wszystkich zestawów znaków - i cyrylica będzie
   wzięta z innego fontu). Problem: Jak znaleźć "podobny" font?

Dodam, że metody a) i b) sprawdzają mi się w praktyce na konsoli tekstowej.
Rzecz jasna lepiej mieć wszystkie potrzebne znaki w foncie, ale nie zawsze
się ma...

Problem związany z tym wszystkim: Jeśli program żąda fontu z wystarczającą
ilością * na innych pozycjach, ale określonym zestawem znaków, to dobrze
by było dać mu w miarę możności font, w którym te znaki są "prawdziwe".

Warto żeby to, co może być niezależne od formatu fontów, takim było.


2. Dostosowanie ważniejszych fontów do nowych realiów.

Czyli generalne porządki, dorysowanie różnych bardziej egzotycznych
znaków, ponazywanie fontów zgodnie z rzeczywistością (w tym rozmiary
i oznaczenia znaków), zrobienie porządku ze sprawą rozdzielczości fontów
bitmapowych, dorobienie xtermowych ramek do wszystkich fontów dla xtermów,
dodanie jakichś fontów, wyrzucenie fontów, które są zdublowane przez
lepsze wersje, pogrupowanie znaków z różnych zestawów znaków danego fontu
w rozłączne zestawy itp.

Do tego warto by zrobić jakieś narzędzia ułatwiające pracę.


3. (ewentualnie)  Postaranie się o jakąś metodę tworzenia słusznej jakości
   fontów wektorowych (czy to TrueType, czy to Type1) oraz dobre fonty
   tego rodzaju na licencji GPL.

Na razie czarno to widzę. Z edytorów fontów Type1 pod Linuxa co najmniej
są dopiero w trakcie tworzenia i AFAIK na razie sporo im brakuje. Ogólnie
dobre fonty TrueType dają lepsze efekty w małych rozdzielczościach niż
mogą dać Type1 - te ostatnie raczej się nie nadają jako całkowity
zamiennik fontów bitmapowych. Za to TrueType są trudniejsze w tworzeniu
i w drukowaniu do Postscriptu.


4. Wymyślenie i zaimplementowanie jakichś mechanizmów, które pozwoliłyby
   wyświetlać się różnym programom we właściwych zestawach znaków bez
   konieczności wbudowywania w każdy taki program bazy danych języków itp.

W szczególności żeby font mógł zależeć od bieżącego locale - czyli od
zestawu znaków, w którym są naprawdę komunikaty.

Należałoby się też dokładnie dowiedzieć, jakie są interfejsy dostawania
się do fontów i znaków, i zastanowić się, czy by nie warto tego usprawnić.
W szczególności pod kątem Unikodu - na przykład byłoby fajnie, gdyby
locale mogło używać zestawu znaków UTF-8 i takie napisy by przyjmowały
biblioteki wyświetlające napisy - program często nie musi wiedzieć, że
jeden bajt to nie jest jeden znak, zwłaszcza w Xach (w odróżnieniu od
konsoli tekstowej), gdzie nie ilość znaków jest ważna, tylko szerokość
napisu w pikselach! Mogą z tym być tylko kłopoty przy edycji pól
tekstowych i być może czasem przy fontach stałej szerokości, przy których
programy polegają jednak na danej liczbie znaków. Trzeba się zastanowić,
w jakim zakresie lepiej używać nazw znaków, a w jakim - numerów Unikodu.


5. Zastanowienie się nad problemem drukowania (czyli praktycznie tworzenia
   Postscriptu) w różnych zestawach znaków. Ogonkify to proteza, która nie
   powinna być potrzebna!


			*	*	*

Bardzo bym chciał, żeby to się nie skończyło na pustym gadaniu.

Osobiście na pewno dużo zrobię przy konkretnych fontach bitmapowych.
Robię różne narzędzia ułatwiające edycję takich fontów - mieszanie znaków
pochodzących z różnych fontów, automatyczne dorysowywanie akcentów
i stosowanie przybliżeń znaków. Rysuję fonty, również bardziej egzotyczne
znaki. Chcę zintegrować tę sprawę z fontami dla konsoli tekstowej - można
używać tych samych fontów tu i tu. Dobrze czuję się w różnych zestawach
znaków i w Unikodzie.

Za to nie znam się na Xowych protokołach i interfejsach, przez co ani nie
umiem wymyśleć szczegółów tego, jak się nasz dodatek powinien zachowywać,
ani nie umiem tego wszystkiego zaimplementować. Nie wiem, w jaki sposób są
w różnych sytuacjach identyfikowane znaki. W każdym razie wydaje mi się,
że najwygodniej wsadzić dostarczanie wirtualnych fontow w zwykły fontserwer
(np. rozbudowując xfsft, który już robi wyciąganie ośmiobitowych tablic
z TT). Nie wiem, jak uzależnić sprawę od locale.

Nie wiem, jak wygląda sytuacja z istniejącymi fontami - jakie fonty
o odpowiedniej licencji są w ogóle dostępne i w jakim stopniu wolno
wzorować się na istniejących fontach o nieodpowiedniej licencji.

Niedawno znalazłem dokładne instrukcje na temat zalecanych reguł
tłumaczenia postscriptowych nazw znaków na Unikod i odwrotnie wraz
z tabelką tłumaczenia. Ale nie wiem, kiedy znaki są identyfikowane
przez nazwę, a kiedy przez pozycję w ośmiobitowym foncie - a także
kiedy _powinny_ być, o ile mamy szansę to zmieniać.

Jeszcze jedno: A może by tak fontserwer udostępniał też fonty TeXowe?
Są jakieś przeciwwskazania techniczne? Trzeba je tylko przemapowywać na
bardziej ludzkie kody znaków, co i tak robimy.

Liczę na Was!

-- 
 __("<   Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.home.ml.org/
 \__/       GCS/M d- s+:-- a21 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-