2020-02-12 o 13:34 +0100, Jarosław Sokołowski napisał:
> wciśnięciu następnego klawisza. Czyli "Alt + ;", a następnie "o" da w
> sumie "ó". Podobnie w przypadku óéśńú... Ale już nie uda się to z
> literą dajmy na to "m" (bo nie ma "m" a kreseczką w żadnym języku).

Hmm... Tak kolega mówi? :)

> Wciskając "Alt + :" uzyskamy podwójny akcent acute, inaczej mówiąc
> węgierski umlaut ő -- ale tylko nad "o", bo tylko taki diakrytyk jest
> w użyciu.

W űżyciű to nie wiem, ale dać się da i z czym innym.

> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň,
> ă, ş i co tam jeszcze może się trafić urzędnikowi stanu cywilnego (i
> nie tylko jemu).

Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z
jakimś UTF-em oraz terminal potrafiący wyświetlać Unicode. Niby
oczywistość w 2020, ale czasem można się zdziwić czego to ludzie
jeszcze używają... Nieco obok tematu ale nie tak bardzo - wczoraj
rano byłem w urzędzie bo im załączniki w mailach się "psuły" więc po
znajomości zajrzałem. Przy tej okazji zauważyłem, że oni jeszcze
działają na Windows XP z Outlook Express, a pocztę ciągną POPem w
cleartext... z ustawieniem "kasuj z serwera po tygodniu" jako sposób na
współdzielenie skrzynki między dwoma komputerami. Od razu poczułem się
młodszy. Swoją drogą - czy Win XP już wspierał Unicode? Chyba nie...

Mateusz

do góry

W dniu 12.02.2020 o 04:48, J.F. pisze:
> Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
> dyskusyjnych:s...@f...lasek.waw.p
l...
>
>> Jak to co znaczy? Po prostu się da. Klawiaturę mam systemową,
>> niezmienioną. Można na niej *łatwo* napisać każde słowo dowolnego
>> języka posługującego się rozszerzonym alfabetem łacińskim (są
>> martwe klawisze).
>
> To wpisz Jarosław po rosyjsku.

Rosyjski to nie alfabet łaciński.

Ale umiem:

???????

:)

MJ

do góry

Pan RoMan Mandziejewicz napisał:

>>>> "Metoda ręczna" i "metoda komputerowa" opiera się o te same zasady,
>>>> tyle że mało kto o tym wie i korzysta z tego.
>>> Mało kto używa TeXa. A ci, którzy używają jednak zazwyczaj wolą
>>> nakładki językowe umożliwiające pisanie bezpośrednio swoich robaczków.
>
>> Się nie zrozumieliśmy. Nie chodziło tu o metodę *drukowania*, tylko o metodę
>> *wprowadzania* znaków z klawiatury, a konkretnie użycie martwych klawiszy.
>> Maszyny do pisania miały jeden taki klawisz, może w niektórych językach dwa.
>> Komputer ograniczeń nie ma, martwych klawiszy w standardowym układzie dla
>> alfabetu łacińskiego jest tyle, ile potrzeba. Jeśli ktoś zna zasadę, napisze
>> wszystko w dowolnym języku. Tak więc kombinacja "Alt + ;" jest martwym
>> klawiszem akcentu acute. Nie przesuwa kursora, tylko dopasuje właściwy
>> robaczek przy wciśnięciu następnego klawisza. Czyli "Alt + ;", a następnie
>> "o" da w sumie "ó". Podobnie w przypadku óéśńú...
>
> Ale o jakim systemie i jakiej klawiaturze piszesz?

Używałem kilku, wszędzie było tak samo. Co nie musi oznaczań, że istnieją
też inne, gdzie jest inaczej. A nawet ułomne, gdzie się w ogóle nie da.

> Metoda znaków martwych występuje również w TeXu. Ale tam ozdobniki są
> opisane słowami i na dłuższą metę jest to niewygodne - stąd moja uwaga
> o nakładkach językowych.

Pierwszy raz spotykam się z określeniem "martwy znak". Zrobienie czegoś
podobnego do martwego klawisza (przypisanie metryce znaku zerowej szerokości)
jest możliwe, ale nikt uczciwy tego nie robi -- to wbrew idei metryk (TFM),
które mają wiernie opisywać, a nie oszukiwać. Jest za to w TeXu mechanizm
akcentowania znaków, który jednak działa *zupełnie inaczej* niż martwe
klawisze. Typowo zdefiniowane jest to nie słowami, lecz intuicyjnymi
sekwencjami -- na przykład \'o oznacza "ó", a \"o oznacza "ö". To bardzo
wygodne przy okazjonalnym pisaniu obcych słów, bo łatwo zapamiętać.

"Typowo" oznacza tak, jak było 38 lat temu. Ale w praktyce bywa różnie,
dzisiaj przeważnie jest inaczej. Sekwencja \'o może umieścić w pliku
wyjściowym po prostu znak "ó" z używanego fontu, który ten znak ma.
I odwrotnie -- napisanie "ó", gdy font jest ubogi w glify, powoduje
zmontowanie tej litery jako znaku akcentowanego. Jest jeszcze trzecia
możliwość -- font witrualny, który ma pliki metryk, a nie ma glifów, a te
dopiero są tworzone w czasie drukowania.

--
Jarek

do góry

Pan Mateusz Viste napisał:

>> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň, ă, ş
>> i co tam jeszcze może się trafić urzędnikowi stanu cywilnego
>> (i nie tylko jemu).
>
> Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z jakimś
> UTF-em oraz terminal potrafiący wyświetlać Unicode.

Nie jest to warunek konieczny. Font postscriptowy w swoim podstawowym
kodowaniu (z początku lat osiemdziesiątych), mimo że ma tylko 256
glifów, również pozwala na to samo -- przy użyciu kompozytów. Wbrew
obiegowej opinii, użycie przy drukowaniu kompozytów nie jest ani
trochę gorsze od drukowania *wcześniej zmontowanymi* literkami.
Te liczne literki z przeróżnymi kreseczmami, istniejące w fontach UTF,
i tak zostały zmontowane w fabryce przez automat. To tylko ułatwienie
dla programów składających, do prostego stawiania literek, jedna obok
drugiej, nie muszą być specjalnie inteligentne.

--
Jarek

do góry

Pan Mateusz Viste napisał:

>> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň, ă, ş
>> i co tam jeszcze może się trafić urzędnikowi stanu cywilnego
>> (i nie tylko jemu).
>
> Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z jakimś
> UTF-em oraz terminal potrafiący wyświetlać Unicode.

Nie jest to warunek konieczny. Font postscriptowy w swoim podstawowym
kodowaniu (z początku lat osiemdziesiątych), mimo że ma tylko 256
glifów, również pozwala na to samo -- przy użyciu kompozytów. Wbrew
obiegowej opinii, użycie przy drukowaniu kompozytów nie jest ani
trochę gorsze od drukowania *wcześniej zmontowanymi* literkami.
Te liczne literki z przeróżnymi kreseczmami, istniejące w fontach UTF,
i tak zostały zmontowane w fabryce przez automat. To tylko ułatwienie
dla programów składających. Do prostego stawiania literek, jedna obok
drugiej, nie muszą być specjalnie inteligentne.

--
Jarek

do góry

2020-02-12 o 15:37 +0100, Jarosław Sokołowski napisał:
> Pan Mateusz Viste napisał:
>
> >> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň, ă, ş
> >> i co tam jeszcze może się trafić urzędnikowi stanu cywilnego
> >> (i nie tylko jemu).
> >
> > Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z jakimś
> > UTF-em oraz terminal potrafiący wyświetlać Unicode.
>
> Nie jest to warunek konieczny. Font postscriptowy w swoim podstawowym
> kodowaniu (z początku lat osiemdziesiątych), mimo że ma tylko 256
> glifów, również pozwala na to samo -- przy użyciu kompozytów.

W druku - tak, da się. Głowica druknie literkę, cofnie się, i dodrukuje
kreseczkę, pałeczkę czy inne kółeczko. Ale jakoś te dane trzeba najpierw
wprowadzić - a zatem i wyświetlić, bo urzędnik musi przecież mieć
WYSIWYG.

> i tak zostały zmontowane w fabryce przez automat. To tylko ułatwienie
> dla programów składających. Do prostego stawiania literek, jedna obok
> drugiej, nie muszą być specjalnie inteligentne.

Programy to jedno, API systemu operacyjnego (przykład z WinXP) to
drugie. No i dochodzi czasem kwestia sprzętu - w trybie tekstowym VGA
(a ten był wielce popularny w administracji jeszcze nie tak dawno
temu), jak byś się nie spiął, to nie wyświetlisz niczego spoza matrycy
256 znaków, bo tam nie ma tak że można sobie gdzieś kreseczkę
domalować (tak, w ten sposób działał egapl.exe, ale on dostawiał
ogonki w pamięci karty VGA, limitu 256 znaków w żaden sposób nie
przeskakiwał).

Mateusz

do góry

Pan Mateusz Viste napisał:

>>>> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň, ă, ş
>>>> i co tam jeszcze może się trafić urzędnikowi stanu cywilnego
>>>> (i nie tylko jemu).
>>>
>>> Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z jakimś
>>> UTF-em oraz terminal potrafiący wyświetlać Unicode.
>>
>> Nie jest to warunek konieczny. Font postscriptowy w swoim podstawowym
>> kodowaniu (z początku lat osiemdziesiątych), mimo że ma tylko 256
>> glifów, również pozwala na to samo -- przy użyciu kompozytów.
>
> W druku - tak, da się. Głowica druknie literkę, cofnie się, i dodrukuje
> kreseczkę, pałeczkę czy inne kółeczko. Ale jakoś te dane trzeba najpierw
> wprowadzić - a zatem i wyświetlić, bo urzędnik musi przecież mieć
> WYSIWYG.

Drukowanie postscriptowe z cofaniem głowicy niewiele ma wspólnego. To nie
na tym polega tworzenie kompozytów. Komputery NeXT do wyświewtlania na
ekranie też używały postscriptu -- trzeba było takie kupić urzędnikom.
To też połowa lat osiemdziesiątych.

Zresztą drukarki igłowe pod koniec swojej epoki też nie cofały -- sekwencję
<literka> <backspace> <kreseczka> drukowały jednym cięgiem.

>> i tak zostały zmontowane w fabryce przez automat. To tylko ułatwienie
>> dla programów składających. Do prostego stawiania literek, jedna obok
>> drugiej, nie muszą być specjalnie inteligentne.
>
> Programy to jedno, API systemu operacyjnego (przykład z WinXP) to
> drugie. No i dochodzi czasem kwestia sprzętu - w trybie tekstowym VGA
> (a ten był wielce popularny w administracji jeszcze nie tak dawno
> temu), jak byś się nie spiął, to nie wyświetlisz niczego spoza matrycy
> 256 znaków, bo tam nie ma tak że można sobie gdzieś kreseczkę
> domalować (tak, w ten sposób działał egapl.exe, ale on dostawiał
> ogonki w pamięci karty VGA, limitu 256 znaków w żaden sposób nie
> przeskakiwał).

Jak działał egapl.exe, wiem dobrze, bo mnie mocno wkurzał. Raz dodać
do matrycy nie wystarczało, przy przełączaniu trybów trzeba było to
robić ponownie, więc program musiał siedzieć w RAM i czuwać nad sprawą.
I to zajmowanie pamięci mnie wkurzało, bo wciąż mi jej brakowało.
Napisałem więc swój program, który w pamięci miał tylko 18 znaków,
a nie całą tablicę 256. Sam w sobie też był mniejszy. Różnica była
kolosalna. To samo zresztą ze sterownikami klawiatury -- ludzie
używali jakichś wielkokilobajtowych pokurcy, mój miał poniżej 200
bajtów.

--
Jarek

do góry

2020-02-12 o 16:19 +0100, Jarosław Sokołowski napisał:
> Drukowanie postscriptowe z cofaniem głowicy niewiele ma wspólnego.

No tak, kolega o niebie a ja o chlebie. :)
Postscript to była, w tamtym stuleciu, droga technologia. Ja miałem na
myśli instrukcje ESC/P, de facto standard w drukarkach igłowych (a
tylko takie widywałem wówczas w administracjach).

> nie na tym polega tworzenie kompozytów. Komputery NeXT do
> wyświewtlania na ekranie też używały postscriptu -- trzeba było takie
> kupić urzędnikom. To też połowa lat osiemdziesiątych.

Być może byłaby to jakaś rada... Ale nie mam przekonania, czy to
dałoby się zakwalifikować jako rozsądne zarządzanie budżetem.

> Zresztą drukarki igłowe pod koniec swojej epoki też nie cofały --
> sekwencję <literka> <backspace> <kreseczka> drukowały jednym cięgiem.

Tu przyznam, że niczego sobie odciąć nie dam - sam miałem Epsona
LX-800, i *wydaje* mi się, że gdy podawałem mu stosowne polecenia ESC/P
w QBasicu w ramach takich właśnie zabaw, to głowica cofała się i
drukowała ponownie w tym samym miejscu, niczym maszyna do pisania. No
ale dawno to było, pamięć omylna, więc może mi się tylko wydaje.

> Jak działał egapl.exe, wiem dobrze, bo mnie mocno wkurzał. Raz dodać
> do matrycy nie wystarczało, przy przełączaniu trybów trzeba było to
> robić ponownie,

Tutaj znów sprzeczność z tym co ja pamiętam - o ile dobrze pamiętam, to
egapl instalował int handler pod 0x10, dzięki czemu był w stanie
domalować na nowo kreski w tablicy VRAM za każdym razem, kiedy ktoś lub
coś zmieniło tryb tekstowy. Dzięki temu sprawa była zupełnie
bezobsługowa.

> więc program musiał siedzieć w RAM i czuwać nad sprawą.

Ano właśnie... więc chyba o tym samym myślimy.

> Napisałem więc swój program, który w pamięci miał tylko 18 znaków, a
> nie całą tablicę 256.

egapl.exe nie miał raczej całej tablicy - tylko właśnie domalowywał
kreseczki i ogonki na ściśle określonych glifach, dzięki czemu był
relatywnie mały. Ale znów - zaczynam mieć wątpliwości co do mojej
pamięci... Może to nie egapl.exe tak robił, tylko plega.exe? Albo jaki
inny polvga.exe? Któryś to robił na pewno, bo pamiętam jeszcze jak
przeczytałem o tym w jakimś CZYTAJ.TXT i pomyślałem "sprytnie!".

> Sam w sobie też był mniejszy. Różnica była kolosalna.

Ciekawią mnie te 18 bajty. Domniemywam, że to był tylko goły int
handler, który uruchamiał przy każdej zmianie trybu jakiś zewnętrzny
program z dysku (typu nierezydentny egapl.exe lub po prostu systemowy
MODE CON CP SELECT...)?

Mateusz

do góry

Pan Mateusz Viste napisał:

>> Drukowanie postscriptowe z cofaniem głowicy niewiele ma wspólnego.
> No tak, kolega o niebie a ja o chlebie. :)

Wydawało mi się, że rozprawiamy o [nie]konieczności używania Unicode.

> Postscript to była, w tamtym stuleciu, droga technologia. Ja miałem
> na myśli instrukcje ESC/P, de facto standard w drukarkach igłowych
> (a tylko takie widywałem wówczas w administracjach).

Droga i powolna. Pecet z programem Goscript (nie Ghostscript) jedną
stronę przygotowywał do druku klika minut. Napisałem wtedy (w języku
postscript) program, który wciągał dowolny font postscriptowy z pliku
i po wyjęciu z niego krzywych Beziera opisujących glify, wypluwał
to w postaci gotowego do kompilacji programu języka Metafont. I to
działało wyśmienicie.

>> nie na tym polega tworzenie kompozytów. Komputery NeXT do
>> wyświewtlania na ekranie też używały postscriptu -- trzeba było
>> takie kupić urzędnikom. To też połowa lat osiemdziesiątych.
> Być może byłaby to jakaś rada... Ale nie mam przekonania, czy to
> dałoby się zakwalifikować jako rozsądne zarządzanie budżetem.

W Polsce w samej końcówce tych lat (a może na początku 90) zakupiono
dla wszystkich urzędów skarbowych komputery marki Bull. Promocja
była, trzeba brać, bo nie wiadomo, czy się powtórzy. Oprogramowania
do tego żadnego. No ale oprogramowanie to drobiazg, tego nawet nie
widać, nie to co taki solidny mebel jak komputer Bull. Oprogramowanie
przecież "się napisze". No i chyba zaczęto pisać, zaliczki wypłacono.
Ale zanim skończono, komputery już poszły na złom, bo wiadomo jak
prawo Moora (i Murphy'ego) działa.

Tak sobie myślę, że ten NeXT przynajmniej działał, więc w zarządzeniu
o jego zakupie rozsądku może być więcej.

>> Zresztą drukarki igłowe pod koniec swojej epoki też nie cofały --
>> sekwencję <literka> <backspace> <kreseczka> drukowały jednym cięgiem.
>
> Tu przyznam, że niczego sobie odciąć nie dam - sam miałem Epsona
> LX-800, i *wydaje* mi się, że gdy podawałem mu stosowne polecenia
> ESC/P w QBasicu w ramach takich właśnie zabaw, to głowica cofała się
> i drukowała ponownie w tym samym miejscu, niczym maszyna do pisania.
> No ale dawno to było, pamięć omylna, więc może mi się tylko wydaje.

Ja sobie dam obciąć (choćby paznokcie) -- ten Epson cofał. Ale drukarki
nowsze/lepsze drukowały jak napisałem. Pozatym była możliwość (nawet
w tych starszych) załadowania swoich znaków, tak jak w kartach EGA/VGA.
Nie trzeba było drukować zacofaną metodą.

>> Jak działał egapl.exe, wiem dobrze, bo mnie mocno wkurzał. Raz dodać
>> do matrycy nie wystarczało, przy przełączaniu trybów trzeba było to
>> robić ponownie,
>
> Tutaj znów sprzeczność z tym co ja pamiętam - o ile dobrze pamiętam,
> to egapl instalował int handler pod 0x10, dzięki czemu był w stanie
> domalować na nowo kreski w tablicy VRAM za każdym razem, kiedy ktoś
> lub coś zmieniło tryb tekstowy. Dzięki temu sprawa była zupełnie
> bezobsługowa.

Raczej ładował całą zawartość generatora znaków, nawet tych ASCII.
Jak się miało lekko nietypową kartę VGA, to w czasie uruchamiania
programu widać było zmianę na ekranie.

>> więc program musiał siedzieć w RAM i czuwać nad sprawą.
> Ano właśnie... więc chyba o tym samym myślimy.
>
>> Napisałem więc swój program, który w pamięci miał tylko 18 znaków,
>> a nie całą tablicę 256.
>
> egapl.exe nie miał raczej całej tablicy - tylko właśnie domalowywał
> kreseczki i ogonki na ściśle określonych glifach, dzięki czemu był
> relatywnie mały. Ale znów - zaczynam mieć wątpliwości co do mojej
> pamięci... Może to nie egapl.exe tak robił, tylko plega.exe? Albo
> jaki inny polvga.exe? Któryś to robił na pewno, bo pamiętam jeszcze
> jak przeczytałem o tym w jakimś CZYTAJ.TXT i pomyślałem "sprytnie!".

Gdyby nie wspomnienie o pliku CZYTAJ.TXT, to bym pomyślał, że to mój.
Mnie się takich opisów nigdy nie chciało robić, bowiem oszczędny w
słowie jestem. A że nigdy na rozsądnie napisany program nie natrafiłem,
napisałem własny.

>> Sam w sobie też był mniejszy. Różnica była kolosalna.
>
> Ciekawią mnie te 18 bajty.

Nie 18 bajtów, tylko 18 znaków: ąćęłńóśźżĄĆĘŁŃÓŚŹŻ.

--
Jarek

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan Mateusz Viste napisał:
>>> Używając innych martwych klawiszy można napisać Ľ, ľ, â, ň, ă, ş
>>> i co tam jeszcze może się trafić urzędnikowi stanu cywilnego
>>> (i nie tylko jemu).
>
>> Pod warunkiem, że urzędnik ma oprogramowanie kompatybilne z jakimś
>> UTF-em oraz terminal potrafiący wyświetlać Unicode.

>Nie jest to warunek konieczny. Font postscriptowy w swoim podstawowym
>kodowaniu (z początku lat osiemdziesiątych), mimo że ma tylko 256
>glifów, również pozwala na to samo -- przy użyciu kompozytów. Wbrew
>obiegowej opinii, użycie przy drukowaniu kompozytów nie jest ani
>trochę gorsze od drukowania *wcześniej zmontowanymi* literkami.

Ale co - chcesz w bazie danych te kompozyty zapamietywać ?
I jak potem wyszukasz "Jarosław", a jak "Łukasz" ?

Niestety - to wymaga calosciowego podejscia - klawiatura, ekran,
programy, baza danych, drukarki ... e-mail.
Albo czekasz az informatyka dorosnie, albo trzaskasz wlasny zamkniety
system ... w assemblerze ?

J.

do góry