🚀 go-pugleaf

On 27 Aug 1998, Piotr Auksztulewicz wrote:

> Nie ma. W drafcie Unikodowym, o ile pamiętam (nie chce mi się w tej chwili
> szukać, a gdzieś mi ten URL znikł) są wszystkie tengwy i tehty, ale nie
> ma kombinacji - trzeba nakładać znaki.

Aha :-(  No to trzeba zrobić, ponumerować wszystkie kombinacje, jeśli
chcemy to wygodnie wyświetlać na konsoli tekstowej. Nie widzę innej rady.
Kłopot w tym, że jeśli nawet my to opracujemy, to może tego wyjść tak
dużo, że nawet w linuksowej części obszaru prywatnego odpowiedzialne za to
osoby mogą mieć opory przed alokacją dużej ilości znaków, jeśli w ogóle
się tam zmieści.

W każdym razie z `man unicode':

PRIVATE AREA
       In the BMP, the range  0xe000  to  0xf8ff  will  never  be
       assigned  any  characters  by the standard and is reserved
       for private usage. For the Linux community,  this  private
       area  has been subdivided further into the range 0xe000 to
       0xefff which can be used individually by any end-user  and
       the  Linux zone in the range 0xf000 to 0xf8ff where exten­
       sions are coordinated among all Linux users. The  registry
       of  the characters assigned to the Linux zone is currently
       maintained  by  H.  Peter  Anvin  <Peter.Anvin@linux.org>,
       Yggdrasil  Computing,  Inc.  It  contains  some  DEC VT100
       graphics  characters  missing  in  Unicode,  gives  direct
       access  to  the  characters in the console font buffer and
       contains the characters used by  a  few  advanced  scripts
       like Klingon.

W części linuksowej są więc tylko 2304 znaki, z czego 512 + 5 jest już
zajęte na bezpośredni dostęp do fontu i znaczki VT100, a klingoński nie
wiem gdzie tam jest.

Możliwości widzę takie:

1. Poddajemy się :-(

2. Sprawdzamy, że nie wyjdzie tak bardzo dużo, i liczymy na to, że po
odpowiednim uzasadnieniu Peter Anvin się zgodzi przydzielić odpowiedni
fragment.

3. Zajmujemy coś w obszarze U+E000..U+EFFF. Tu się na pewno zmieści,
ale ryzykujemy konflikty i to odpada jako sposób przechowywania tekstów -
raczej tylko jako tymczasowe wyświetlanie po konwersji w locie.

4. Zajmujemy na dziko coś powyżej U+10000. W razie czego kiedyś później
się wszystko przesunie gdzieś indziej. Ewentualnie najpierw dowiadujemy
się gdzieś, które regiony najlepiej wolno wykorzystać.

5. Próbujemy (tzn. głównie ja musiałbym się tym zająć; kiedyś na
przyszłość i tak to planowałem) implementować ogólny mechanizm nakładania
akcentów i ewentualnie dopieszczony istniejące kodowanie, żeby wszystko
wyszło porządnie - dynafont będzie dokładał akcenty. Kłopot (duży) jest
taki, że jeśli w końcu powstaną porządne edytory unikodowe, to zapewne nie
będą potrafiły uwzględniać nakładanych akcentów, a gdyby nawet próbowały,
to nie bardzo jest jak sprawdzać, które znaki konsola traktuje jako
dokładane akcenty.

6. Robimy tylko jakąś paskudną wersję z tehtami jako samodzielne znaki :-(

Bardzo chciałbym wykluczyć możliwości 1 i 6.

> Można zrobić kilka dla różnych języków. Quenejski, sindariński,
> angielski, polski... Tylko że to jest pismo fonetyczne i naciskając
> klawisze "ortograficznie" nie uzyska się poprawnego napisu, chyba żeby
> jakiś bardzo inteligentny konwerter napisać.

O ile z mapą klawiatury może być gorzej, o tyle do samej konwersji
z transkrypcji fonetycznej mój konwerter się nada, o ile tę transkrypcję
da się wystarczająco ściśle opisać. Robiłem już konwersję rosyjskiego na
polską transkrypcję fonetyczną (tzn. wychodzi np. Sojuz Sowietskich
Socyalisticzeskich Riespublik) i konwersję z naszej ortografii na inne.
Są właściwie tylko dwa specjalne środki: zamiana tekstu zależna od
sąsiedztwa oraz zbiory znaków. To wystarcza do różnorakich transkrypcji
fonetycznych i np. w podobny sposób program syntezy mowy SAM na Commodorze
64 miał zapisane reguły konwersji angielskiego tekstu na wymowę - na jego
pomyśle się zresztą wzorowałem.

Nie da się tylko wyrazić rzeczy typu "dowolny ciąg spółgłosek zakończony
samogłoską" - wszystko musi mieć ustaloną długość - i na razie nie ma
przełączalnych na stałe kontekstów. Do nieinteraktywnej konwersji
wystarcza, a do mapy klawiatury czasem trzeba kontekstów, jeśli np. co
drugie wystąpienie danego znaku powinno być traktowane inaczej, a po
każdym naciśnięciu coś ma się dziać - taki kłopot miałem z esperancką
klawiaturą w stylu Zamenhofa, czyli ch gh hh jh sh u zamiast c g h j s u
z akcentami, kiedy pierwsze naciśnięcie h powinno dać h, drugie powinno
dołożyć akcent (czyli skasować tamto i dodać h akcentowane), trzecie
napisać kolejne h itd. - tego się nie da wyrazić w moim konwerterze,
a dałoby się po wprowadzeniu zmiennych. W nieinteraktywnej konwersji nie
ma tego problemu - po prostu para hh jest zastępowana jako całość. Problem
więc polega głównie na tym, że same transkrypcje są pewnie słabo
ustandaryzowane i nie pozwalają oddać potrzebnych różnic.

-- 
 __("<   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-