Article View: pl.comp.ogonki
Article #7051Re: Quenejskie locale
From: Marcin 'Qrczak' Kowalczyk
Date: Sat, 29 Aug 1998 12:46
Date: Sat, 29 Aug 1998 12:46
262 lines
13643 bytes
13643 bytes
On Sat, 29 Aug 1998, Gwidon S. Naskrent wrote:
> #>Juhuuu, zrobilem dokladane akcenty! Jeszcze nie testowalem wszystkich
> #>wariacji, ale wyglada na to, ze dziala. Mozna nawet definiowac w foncie
> #>zlozenia jako samodzielne znaki, np. U+0045+0328. Jesli znak jest
> #>niedostepny, to jest fizycznie skladany z kawalkow. Wszystko niezaleznie
>
> Co to znaczy 'skladany z kawalkow'? To znaczy jak to jest technicznie
> robione, bo nie pamietam zeby norma ANSI pozwalala na pisanie _na_
> jakims znaku?
Technicznie dynafont rysuje sobie nowy znak w jakiejś wolnej pozycji (albo
wyrzucając najdawniej używany znak, jeśli nie ma już miejsca), wrzuca
uaktualniony font wraz z mapą SFM na konsolę i w przypadku znaków innych
niż zwyczajne U+0000..U+FFFF (czyli wyższe numery, złożenia znaków nie
mające samodzielnych kodów, podkreślenia i od dzisiaj również pogrubienia,
jeśli się włączy opcję) wyrzuca odpowiedni znak U+Exxx z obszaru
straight-to-font zamiast oryginalnego znaku. Właściwie to można by nie
bawić się w SFM i wszystko robić przez zakres straight-to-font. W sumie
udało mi się w miarę prosto zaimplementować te wszystkie możliwości, nawet
z możliwością zdefiniowania w foncie znaku przez samo opisanie złożenia,
bez indywidualnego rysunku, albo bez konieczności przydzielania pojedynczych
kodów rysunkom opisującym złożenia, które zrobione automatycznie by źle
wyglądały.
Złożenia są używane kiedy program wyemituje kolejne znaki bezpośrednio po
sobie, bez kodów sterujących pomiędzy. Program pisze np. E (dynafont pisze
E), program pisze ogonek (dynafont pisze \b oraz Ę [E z ogonkiem], przy
czym znak może być albo złożony samodzielnie, albo wzięty z fontu
z pozycji Ę [E z ogonkiem], albo wzięty z fontu z pozycji opisanej jako
E + ogonek).
> No tak, ale to tylko wskazowka dla projektantow fontow, nie majaca
> znaczenia praktycznego przy obrobce tekstow (nie wyswietlaniu, tylko
> obrobce).
Kiedy ja właśnie zrobiłem wyświetlanie; bardzo się to przydaje. Inaczej
musiałbym albo dodać to samemu, albo robić jakieś heurystyki, rozpoznając,
czy akcent jest raczej bliżej góry znaku czy dołu - a jeszcze akcenty mogą
być "przyklejone" albo nie.
> #>moze miec odstep jednego albo dwoch pikseli miedzy kropkami). Nie liczac
> #>oczywiscie wyjatkow, np. czeskich Ľ ď ľ ť [L d l t z ptaszkami], ktore,
> #>choc "logicznie" (np. w rozkladach unikodowych) maja ptaszki, w wygladzie
> #>maja jakby przecinki; albo g z cedilla i oczywiscie gubienie kropek przez
>
> To nie przecinek, tylko znak o kodzie 8217 (closing 9 quotation mark).
Właśnie że "logicznie" to jest caron. Widać to chociażby po odpowiednikach
duże-małe. Tylko wygląda jak przecinek nad niektórymi literami.
> #>Najwiekszy problem jest taki, ze kazdy edytor na tym zglupieje - zle
> #>policzy znaki. Chyba ze bedzie w nim specjalnie zaimplementowane specjalne
>
> :( A co z owa slynna poprawka do basha?
Też zgłupieje oczywiście.
> #>Tylko z konwersja nie ma problemow, a do wyswietlania na szczescie
> #>lessowi nie przeszkadza, ze "nie zgadza sie" ilosc znakow w linii - do
> #>wyswietlenia tekstow w Unikodzie i tak trzeba ustawic dla lessa
> #>COLUMNS=duzo, zeby nie lamal zbyt wczesnie. Dokladane akcenty
>
> Duzo to znaczy ile?
Ilekolwiek, może być za dużo. W ekstremalnym przypadku może się zdarzyć
6 * szerokość ekranu w znakach, a z dokładanymi akcentami jeszcze więcej.
> Zauwaz ze nie wyswietlam tylko tekstow unikodowych, wiec moze jakis
> alias? uniless? Jest do tego jakas opcja (-c, --columns ?)
Ja robię "COLUMNS=800 less plik".
Jeśli plik nie ma wierszy dłuższych niż szerokość ekranu, to to nie
przeszkadza przy normalnych plikach. A jeśli wiersze są dłuższe, to
posypie się i na unikodowych, i nie widzę na to rady, bo każda linia może
mieć inną liczbę bajtów.
> Ooops, PPST oczywiscie. Pierwsza Polska Strona Tolkienowska,
> http://www.lodz.tpsa.pl/iso/Tolkien/.
Dzięki, cudowny transfer i ciekawa treść. BTW: Rymy pierścienia w różnych
językach aż się proszą, żeby były i w Unikodzie; teraz są miejscami
krzaki, których nawet dałoby się czasem uniknąć w obecnym kodowaniu (bywa
8bit zamiast encji w przypadku zachodnich języków i vice versa).
> #>Juz nieaktualne! Wystarczy, zeby byl dobrze zdefiniowany zestaw
> #>nakladajacysh sie akcentow.
>
> Hm, nadal nie rozumiem jak robisz to bez zdefiniowania gotowych znakow
> (albo chociaz ich kodow - co bedzie jak to zapisze do pliku?), ale coz,
> nie mozna pojac wszystkiego :-)
To nie służy do pisania do pliku, tylko wyświetlania na ekranie, przez
filterma. Konwersja z zapisem do pliku nie wyprodukuje niczego ciekawego
(normalne znaki przejdą bez zmian, rozszerzone zamienią się w różne
znaczki U+E000-U+1FFF i w czasie konwersji setki razy zmieni się font na
konsoli, o ile zostanie znaleziony deskryptor terminala (nie jestem
pewien)).
Podobną konwersję do pliku mógłbym zrobić niezależnie od tego - można
"skompresować" te znaki z akcentami, które mają przypisane samodzielne
kody. Mogłoby to się przydać, jeśli jakiś program produkuje znaki składane
z akcentów w przypadku kiedy one mają samodzielne kody i chcemy uzyskać
równoważny, ale mniejszy plik i mniej zależny od wyświetlania sklejanych
znaków.
> Niestety tego nie ma :( Moglbym narysowac samemu, ale moje zdolnosci
> graficzne sa rowne zeru (jesli chodzi o rysowanie od podstaw - ogonki to
> tam jeszcze jakos domaluje).
W takim razie spróbuję w wolnej chwili to narysować (chwilowo tych wolnych
chwil nie mam zbyt dużo). Dokumenty, które mam, są wystarczająco dokładne.
Ale konwersji ani map klawiatury już nie dam rady z powodu zbyt małej
znajomości strony merytorycznej. Za to już wiem, jak będą wyglądały
zmienne i warunkowe reguły w trsie, więc mapę klawiatury będzie w czym
robić. Mogę samemu przerobić konwersję tekstu na mapę klawiatury, ale
muszę mieć tę konwersję. Oczywiście dla każdego języka niezależnie.
> #>> Chociaz w drafcie nic takiego nie ma.
> #>
> #>No to trzeba wprowadzic! W Unikodzie kazdy znak ma przypisana "kategorie"
> #>i np. Mn to non-spacing mark. Takie musza byc tehty, rozniaste tyldy itp.
>
> Tam nie ma zadnych kategorii :( Wydaje mi sie ze to dopiero nastepuje
> w momencie zatwierdzenia oficjalnego (bo inne proponowane alfabety tez
> nic nie maja).
(Teraz jestem już po przejrzeniu tamtego) Właśnie że w zasadzie są!
Może nie są wprost opisane, ale jest wyraźny podział na normalne znaki
i dokładane akcenty. Wszystko widać na załączonym tam obrazku i nie ma
chyba wątpliwości, który znak jest który i do czego służy.
> #>> Protestuje przeciwko takiemu ohydnemu neologizmowi jak trutajp ;-)
> #>
> #>Co proponujesz w zamian? :-) (Tylko nie True Type - to ma byc polskie
> #>slowo, ktore normalnie mozna zapisac i odmieniac.)
>
> Nic nie proponuje. Pisz "czcionki TT" i juz. Skrotowcow sie nie odmienia
> (przewaznie).
No właśnie, nie odmienia się - a język polski ma to do siebie, że lubi
odmieniać słowa, więc zapożyczenia, które dają się odmieniać, są ogólnie
lepsze. Poza tym "fonty", a nie "czcionki" :-P
> #>nawet moze to byc jedna z wersji ogonka. Drugie podejscie jest dla mnie
>
> Wersja ogonka jest tylko jedna, bo TT musi sie stosowac do standardu
> Unicode, a o ile wiem, tam nie ma roznych ogonkow.
Jako osobne znaki nie ma, ale nigdzie nie jest powiedziane, że ogonek pod
wszystkimi literami musi wyglądać dokładnie tak samo - niezależnie od
tego, czy do tych liter dostajemy się przez indywidualne kody, czy przez
złożenia. Tylko od formatu fontów i implementacji zależy, czy da się to
wygodnie zrobić. Samodzielny ogonek do małego ę [e z ogonkiem] (o ile ma
wyglądać inaczej niż pozostałe) nie będzie dostępny pod konkretnym
numerem, tylko będzie użyty do produkcji tej litery. Ale nie będzie
dostępny pod żadnym numerem jako samodzielny znak. Chodzi o to, żeby
w definicjach wszystkich akcentowanych liter nie trzeba było powielać
za każdym razem kształtu danej litery.
> A niektorzy "producenci" fontow tak wlasnie robia (ogonek nakladany,
> czesto zreszta w niestandardowej pozycji).
Każdy dobry pomysł można spiep* w wykonaniu!
> Korzysci sa wymierne, wady - olbrzymie (przede wszystkiem
> niespojnosc).
To zależy od formatu fontów. Oczywiście jeśli format nie umożliwia takich
numerów i np. nie pozwala definiować kawałków znaków, które nie będą
dostępne bezpośrednio, to trzeba definiować każdą literę niezależnie, ale
idea sama w sobie jest bardzo naturalna.
> #>> Tengwy! L.p. tengwa, l.mn. tengwary. Slowo jest quenejskie, wiec odmienia
> #>> sie odpowiednio.
> #>
> #>"Tengwara", czyli alfabetu, a nie litery.
>
> No to "alfabetu tengwarowego".
W takim razie co znaczy słowo "tengwar"?
> #>> A co ze znaczkami ktore moga wystepowac na dole?
> #>
> #>Dokladnie to samo, co ze znaczkami na gorze.
>
> No tak, ale one moga wystepowac lacznie!
Nie szkodzi, składanie może być u mnie wielokrotne, a maksymalna ilość
akcentów jest kwestią z#definiowania jednej stałej. Funkcja starająca się
wyprodukować dany znak, który jest niedostępny, wywołuje rekurencyjnie
siebie dla części "bez ostatniego akcentu", o ile udało się znaleźć
rozkład znaku. A wielokrotne akcenty z jednej strony będą umieszczane
kolejno pod sobą tudzież nad sobą - doklejam do fizycznego obrazka znaku,
nie patrząc, czy już miał jakieś akcenty. Znak się tylko trochę pogniecie
kiedy już nie będzie miejsca z danej strony na akcent.
> #>> Nieeeee, tylko nie to znowu! Teraz zaczniesz moj piekny uklad
> #>> przerabiac, i to calosciowo, bo przeciez i to tehta, a j - tengwa!
> #>
> #>Akurat z ostatnimi szescioma wyrazami sie zgadzam :-)
>
> A z czym sie nie zgadzasz?
Właściwie to z resztą też się zgadzam :-)
> #>> Nie chce slyszec o zadnych 35 spolgloskach. Ja zakodowalem okolo 25
> #>> (zadnych tam miekkich k, g, p, t...) a palatalizacje zaznaczam tehta.
> #>
> #>A pfuj!
>
> Na co "pfujasz" - na to ze nie chce slyszec, czy na to ze zaznaczam?
Przede wszystkim na to drugie.
> No widzisz, a teraz juz jest.
No ale nie mam, nigdy nie widziałem i nie widzę, skąd można by zdobyć :-(
> Tylko nie bierz do reki Lozinskiego, bo nie recze za przeklad tego
> dodatku (chociaz wlasciwie jest on moze nawet lepszy od reszty
> ksiazki, nie czytalem).
Wiem, czytam czasem sf-f!
> Wiec odrozniam... sluchaj, tego nie bylo w zadnym z jezykow Srodziemia,
> wiec trzeba cos wymyslic. Wiem ze popelniam vinyakarie*, czyli grzech
> smiertelny tolkienisty, ale badz tu madry...
Ale sposób rozróżnienia... Przecież ć [c z kreską] jest takim samym
"miękkim odpowiednikiem" t, jak l jest odpowiednikiem ł [l skreślone].
> A jak chcesz zaznaczac ta miekka spolgloske? Tylko nie mow ze przypiszesz
> temu nowa tengwe, bo nie wiem gdzie ja zmiescisz (pamietaj ze masz sie
> trzymac chociaz czesciowo klucza fonetycznego). Krotko mowiac, wypedziles
> diabla Belzebubem.
Ponieważ rzeczywiście tengw nie starcza bez sztucznych przyporządkowań
(ale jeszcze sprawdzę, jak sztuczne by wyszły), można by zrobić dodatkowy
znaczek na miękkość (a raczej wykorzystać któryś istniejący do innego
celu), ale jednolity do wszystkich zmiękczeń, nawet tych "logicznych".
> #>Nie wiem, ktore dokladnie sa te wszystkie! Jest mnostwo wyjatkowych
> #>elementow, ktore mozna doklejac do przeroznych rzeczy, po pare naraz,
> #>i sie troche gubie.
>
> Zalozmy na razie ze "wszystkie" = quenya, sindarin, adunaicki, westron,
> angielski, polski. Ok?
Miałem na myśli, które to są te wszystkie litery. Ale w nowej
rzeczywistości nie jest to takie ważne, bo wszystko można w każdej chwili
dodać i w dowolnej kolejności (jeśli nie będzie dodane, to najwyżej się
brzydko wyświetli - tutaj nie wszystko można wygodnie zrobić automatycznym
doklejaniem akcentów i często trzeba rysować indywidualne znaki).
--
__("< 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-
Technical Details
Message-ID:
<Pine.LNX.4.01.9808291346360.1092-100000@qrnik.knm.org.pl>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!mat.uni.torun.pl!uw.edu.pl!newsgate.cistron.nl!het.net!195.200.0.51.MISMATCH!newshub.bart.net!ayres.ftech.net!news.ftech.net!newsfeed.nacamar.de!sunqbc.risq.qc.ca!wesley.videotron.net!Pollux.Teleglobe.net!orion.cst.tpsa.pl!news.tpnet.pl!not-for-mailReferences:
<Pine.BSF.4.02A.9808291039420.263-100000@hoth.amu.edu.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!mat.uni.torun.pl!uw.edu.pl!newsgate.cistron.nl!het.net!195.200.0.51.MISMATCH!newshub.bart.net!ayres.ftech.net!news.ftech.net!newsfeed.nacamar.de!sunqbc.risq.qc.ca!wesley.videotron.net!Pollux.Teleglobe.net!orion.cst.tpsa.pl!news.tpnet.pl!not-for-mail From: Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> Newsgroups: pl.comp.ogonki Subject: Re: Quenejskie locale Organization: Klub Nieszkodliwych Manjaków Lines: 263 Message-ID: <Pine.LNX.4.01.9808291346360.1092-100000@qrnik.knm.org.pl> Mime-Version: 1.0 In-Reply-To: <Pine.BSF.4.02A.9808291039420.263-100000@hoth.amu.edu.pl> References: <Pine.BSF.4.02A.9808291039420.263-100000@hoth.amu.edu.pl> Date: Sat, 29 Aug 1998 12:46:29 GMT NNTP-Posting-Host: 195.116.251.52 X-Complaints-To: abuse@tpsa.pl X-Trace: news.tpnet.pl 904394789 195.116.251.52 (Sat, 29 Aug 1998 14:46:29 MET DST) NNTP-Posting-Date: Sat, 29 Aug 1998 14:46:29 MET DST Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit