Klawiatura

Zagadnienie wprowadzania polskich liter ze standardowej klawiatury PC zostało - jak sądzę - we właściwy sposób przedstawione m.in. na łamach czasopisma „Komputer". Sprowadza się ono do koegzystencji standardu w ścisłym sensie, nazywanym dalej klawiaturą maszynistki, i standardu de facto, nazywanego dalej klawiaturą programisty. Zajmijmy się najpierw tym drugim.

Istotą klawiatury programisty jest wprowadzanie polskich liter za pomocą klawisza [Alt]. Sprawa nie budzi wątpliwości dla większości polskich liter, mianowicie dla

ąĄćĆęĘłŁńŃóÓśŚ które wprowadzane są odpowiednio przez [Alt]-[a], [Shift]-[Alt]-[a] itd. Problem pojawia się dopiero przy literach ź (Ź) i ż (Ż), z których tylko jedna może być przypisana kombinacji [Alt]-[z] ([Shift]-[Alt]-[z]). Osobiście od lat stosuję na różnych komputerach konwencję sformułowaną następująco. Literę ź (Ź) wprowadzamy analogicznie jak ć, ń, ó, ś (Ć, Ń, Ó, Ś) -a więc w wypadku PC przez [Alt]-[z] ([ShiftHAltHz]); literę ż (Ż) wprowadzamy stosując analogiczną modyfikację - a więc w wypadku PC klawisz [Alt] - do litery r (R), ponieważ wymowa ż jest identyczna jak dwuznaku rz. Jak się wydaje, dość szeroko jest stosowana konwencja odmienna, polegająca na wprowadzaniu litery ź (Ź) przez [Alt]-[x] ([Shift]-[Alt]-[x]), a litery ż (Ż) przez [Alt]-[z] ([Shift]-[Alt]-[z]).

Klawiatura maszynistki to polski oficjalny standard układu klawiatury maszyny do pisania, stosowany przez kwalifikowane maszynistki i osoby piszące bezwzrokowo. Wykwalifikowany personel musi mieć zapewnioną możliwość przełączania klawiatury w ten tryb pracy, ale trybem domyślnym powinna być klawiatura programisty. Dla osób piszących bezwzrokowo oznakowanie klawiszy nie jest rzeczą najistotniejszą, ale byłoby pożądane, aby lokalizacja polskich liter na klawiaturze maszynistki była opisana np. na przednich ściankach klawiszy (takie klawiatury są już produkowane). Jest kwestią otwartą, czy w klawiaturze maszynistki niektóre znaki ASCII stają się niedostępne, czy też można je wprowadzać za pomocą klawisza [Alt]. Jeżeli przyjmiemy, że zmiana trybu pracy klawiatury odbywa się łatwo, to jestem za rozwiązaniem pierwszym jako koncepcyjnie prostszym.

Niemal każdy zaawansowany użytkownik komputera stosuje dla ułatwienia sobie pracy różne mechanizmy przedefiniowywania klawiszy i ich kombinacji; mechanizmy takie zawierają się w niektórych programach aplikacyjnych (np. lepsze edytory) i środowiskach operacyjnych (np. DESQ-view) lub dostępne są w postaci osobnych programów rezyden-tnych (np. SuperKey). Zarówno klawiatura programisty, jak i klawiatura maszynistki mogą być zrealizowane - choć niekiedy z ograniczeniami dotyczącymi kombinacji [Shift]-[Alt] - za pomocą tych narzędzi, które jednak nie zawsze pozwalają na łatwą zmianę trybu. Głównie z tego powodu pożądane byłoby rozwiązanie bardziej zintegrowane z systemem operacyjnym DOS, np. w postaci programu obsługi klawiatury (ang. driver), z ewentualnymi parametrami (pozwalającymi np. wybrać ulubioną reprezentację ź i ż) specyfikowa-nymi w zbiorze CONFIG.SYS.

Rozważmy obecnie, jak zmieniać tryb pracy klawiatury. Rozszerzenie systemu PC-DOS dla języków słowiańskich, noszące nazwę IBM PS/2 Natural Language Sup-port stosuje następującą konwencję. Przełączenie z klawiatury standardowej np. na cyrylicką odbywa się za pomocą [Alt]-[Ctrl]-[F2], powrót do klawiatury standardowej za pomocą [Alt]-[Ctrl]-[Fl] (w trybie klawiatury standardowej litery cyrylickie mogą być wprowadzane przy pomocy prawego klawisza [Alt] noszącego nazwę Alter-native Graphics Key, w razie potrzeby razem z klawiszem [Shift]; w analogiczny sposób dostępne są litery łacińskie z klawiatury cyryli-ckiej). Osobiście wolę jednak rozwiązanie zaobserwowane w jednym z programów typu public do-main, gdzie przełączenie trybu klawiatury odbywa się za pomocą klawisza [Scroll Lock]. Jego zaletą jest wizualna sygnalizacja aktualnego stanu klawiatury, wadą - potencjalne konflikty z programami aplikacyjnymi (nie znam jednak żadnego konkretnego przykładu).

Dla szerokiej akceptacji przyjętych ustaleń byłoby bardzo pożyteczne opracowanie programów nauczających wprowadzania do komputera tekstów polskich metodą bezwzrokową (typu Typing Tutor czy PC-Fasttype).

2. Kodowanie

Stosowany dla komputerów IBM PC sposób kodowania liter narodowych, wprowadzony przez IBM i Microsoft, a dla kompatybilności przejęty również przez konkurencję (np. Digital Research), budzi wątpliwości już na poziomie koncepcyjnym. Opiera się on na pojęciu stron kodowych (ang. code pages), czyli różnych rozszerzeniach kodów ASCII, przy czym system plików systemu DOS nie pozwala w żaden sposób określić, w jakim kodzie jest zapisany dany plik tekstowy. Co więcej, w praktyce korzystanie z niektórych stron kodowych podlega zupełnie arbitralnym i niezrozumiałym ograniczeniom ze strony producentów - np. aby korzystać z cyrylicy w systemie MS-DOS, trzeba kupić rosyjską wersję tego systemu (tj. z komunikatami i innymi tekstami systemowymi, a także podręcznikami przetłumaczonymi na rosyjski), choć wystarczyłoby udostępnić zbiory typu EGA.CPI zawierające odpowiednie fonty. Wydaje się, że wprowadzając strony kodowe producenci nie zdawali sobie sprawy z faktycznych potrzeb użytkowników, a jedynie dążyli do ułatwienia sobie dystrybucji różnych wersji systemu. Tego sposobu myślenia nie waham się określić jako staroświecki: wobec postępującej integracji i zacieśniania się kontaktów międzynarodowych, konieczność przetwarzania na komputerze tekstów różnojęzycznych staje się bowiem coraz bardziej powszechna.

Z punktu widzenia użytkownika polskiego najbardziej istotna jest strona kodowa 852 (nazywana także Latin-2). Opracowana podobno jeszcze w 1985 r., przejawia cechę nazywaną przeze mnie syndromem żelaznej kurtyny. Zakłada ona, że użytkownik w kraju obecnie post-komunistycznym będzie przygotowywał na komputerze teksty niemieckie (NRD!), polskie, słowackie, czeskie, słoweńskie, chorwackie, albańskie, rumuńskie i węgierskie, ale nie będzie potrzebował pisać tekstów po francusku (brak liter a, e, i, u, ii) czy po włosku (brak liter a, e, i, ó). Jest to dla mnie wystarczający powód, by zrezygnować ze stosowania tej strony kodowej (w czym całkowicie zgadzam się m.in. z Władysławem Majewskim i Andrzejem Gecowem ostro wyrażającymi swoje poglądy na łamach „Computerworld" i „PC Kuriera"). Nie można uznać za usprawiedliwienie faktu, że syndrom żelaznej kurtyny jest widoczny w całej chyba międzynarodowej działalności normalizacyjnej, np. w normie ISO8859 i kodach telegazety.

Stronie kodowej 852 zarzuca się również ubogi zestaw znaków semigraficznych, w rzeczywistości sprawa jest nieco bardziej złożona. Mianowicie strona ta zawiera takie same znaki semigraficzne, jak dostępna w standardowej dystrybucji systemu DOS tzw. międzynarodowa strona kodowa 850; są to ramki pojedyncze i podwójne, brak natomiast połączeń ramek pojedynczych z podwójnymi. O ile mi wiadomo, strona 850 jest dość szeroko stosowana w krajach zachodnich (jej zaletą jest m.in. zgodność zestawu znaków z międzynarodową normą ISO8859-1). Wydaje się zatem, że dobrze zaprojektowany program nie powinien korzystać ze znaków semigraficznych niedostępnych w stronie 850, a więc i w stronie 852. Dalsze ograniczanie zestawu znaków semigraficznych wydaje się niepożądane i niepotrzebne.

Spośród stosowanych w kraju sposobów kodowania polskich liter, podobno najbardziej rozpowszechniony jest tzw. kod Mazowii - w każdym razie tak twierdzą jego zwolennicy, bardzo aktywni na lamach polskich czasopism informatycznych. Jest to modyfikacja podstawowej strony kodowej 437, z której zostały usunięte następujące znaki:

• litery a i A, występujące w języku szwedzkim, duńskim i norweskim (kody 134 i 143, litery

ą i Ą)

• litera i, występująca przede wszystkim we włoskim (kod 140, litera ć)

• litera E, występująca m.in. w języku francuskim, włoskim i portugalskim - w języku francuskim może być zastąpiona przez E, nie wiem, jak sprawa wygląda w innych językach (kod 144, litera Ę)

• litery ae i AE, występujące w duńskim i norweskim (kody 145 i 146, litery ę ił)

• litera ó, występująca we włoskim i portugalskim (kod 149, litera ć)

• litera y, używana głównie w walijskim, dawniej również we francuskim (kod 152, litera Ś)

• znak funta .L (kod 156, litera Ł)

• znak Pt (kod 158, litera ś)

• litera a, występująca m.in. w hiszpańskim i portugalskim (kod 160, litera Ź)

• litera i, występująca m.in. we włoskim i portugalskim (kod 161, litera Ż)

• litera u, występująca m.in. we włoskim, hiszpańskim i portugalskim (kod 163, litera Ó)

• litery ń i Ń występujące głównie w języku hiszpańskim (kody 164 i 165, litery ń i Ń)

• znaki - i - (kody 166 i 167, litery ź i ż).

Litera ó występująca w stronie 437 na pozycji 162 zachowuje tę pozycję w kodzie Mazowii.

W znanych mi tabelach kodu Mazowii występują pewne różnice dotyczące znaków § i zł. Nie występują one w tabeli z 1988 r. podanej w piśmie „Microklan" (nr 7) i w tabeli opublikowanej ostatnio przez „PC Kurier" (nr 25/90). Natomiast w tabeli podanej przez Andrzeja Gecowa w „PC Kurierze" nr 25/90 znak centa (c) i hiszpański znak otwierający zdanie py-tajne (6), występujące w stronie 437, są zastąpione przez § (kod 155) i zł (kod 168). Swoją drogą, dziwne wydaje mi się pominięcie we wszystkich tych tabelach polskiego otwierającego cudzysłowu („), w moim przekonaniu o wiele bardziej potrzebnego od symbolu złotówki.

Oczywistą motywacją takiego a nie innego przypisania kodów znakom polskim były walory mnemotechniczne, ułatwiające czytanie zakodowanego w ten sposób tekstu polskiego wyświetlonego na ekranie lub wydrukowanego na ekranie lub wydrukowanego na drukarce w zestawie znaków strony 437. Motywacja ta nie ma już racji bytu, ponieważ większość stosowanych obecnie kart graficznych umożliwia programowanie generatorów znaków (tzw. RAM-fonts), a dobrej klasy drukarki pozwalają również korzystać z programowo definiowanych fontów. Tak więc ze współczesnej perspektywy kod Mazowii przedstawia się jako przypadkowy i niesystematyczny.

Jakie można wyciągnąć wnioski z tych rozważań? Zgadzam się z poglądem, że strona kodowa 852 jest mniej przydatna od kodu Mazowii w sytuacjach, kiedy trzeba wybrać tylko jeden zestaw znaków (np. jeśli przystosowanie do języka polskiego może się odbyć jedynie drogą modyfikacji sprzętowej), lepiej jest więc zdecydować się na ten ostami. Rozwiązaniem optymalnym byłoby jednak zaakceptowanie przez producentów i użytkowników przejściowej koegzystencji dwóch lub trzech standardów: strony kodowej 852, kodu Mazowii i nowego (w zamierzeniu ostatecznego) kodu, który powinien być wypracowany stopniowo, bez nerwowości i pośpiechu.

Sformułowanie konstruktywnej propozycji nowego standardu dla polskich liter wykracza poza ramy tej notatki, wydaje mi się jednak, że powinien on bazować na stronie kodowej 850, w której można wygospodarować wolne miejsca przez usunięcie takich znaków jak §, które występują w zestawie dwukrotnie, ułamków 1/2, 1/4

3/4, indeksów górnych

1 2 3

itp.

Gdyby okazało się, że ważne względy przemawiają za zachowaniem niektórych wytypowanych przeze mnie znaków, wówczas należałoby konsekwentnie usunąć litery niektórych mało używanych w Polsce języków, np. thorn (?) i inne litery islandzkie, pozostawiając w spokoju języki bardziej dla nas pożyteczne, jak włoski, hiszpański, portugalski i języki skandynawskie.

Chciałbym mocno podkreślić, że wprowadzenie nowego standardu nie musi być kataklizmem. Można to zrobić bezboleśnie na co najmniej dwa sposoby. Robiąc to powoli, należy najpierw nadać standardowi status rekomendacji, ustalając jednocześnie konkretną, ale realistyczną datę jego pełnego wprowadzenia w życie - okres ten pozwoli producentom oprogramowania i użytkownikom przygotować się do nowego standardu w trakcie naturalnego rozwoju oprogramowania, a więc przy minimalnych kosztach dodatkowych.

Można to również zrobić szybko, wprowadzając formalny lub nieformalny standard metodą faktów dokonanych, ale należy tak postępować tylko przy zapewnieniu dostępności narzędzi służących do konwersji z dotychczasowych standardów na nowy.

3. Ekran i drukarka

Po ustaleniu sposobu kodowania polskich liter, ich wyświetlanie na ekranie za pomocą kart wyposażonych w programowany generator znaków nie stanowi w zasadzie problemu. W przypadku drukarek sprawa jest bardziej złożona ze względu na ich większą różnorodność i ograniczenia dotyczące fontów definiowanych programowo. Jak twierdzi Andrzej Gecow w „PC Kurierze", programowa implementacja strony 852 na dotychczas sprowadzanych drukarkach jest praktycznie niemożliwa (wyróżnienie moje). Mam nadzieję, że można sprowadzać drukarki, dające pełną swobodę programiście w definiowaniu własnych fontów. Tak czy inaczej, moim zdaniem, zasadniczym problemem jest integracja przyjętego standardu z systemem operacyjnym.

Koncepcyjnie najprostsze, bo uogólniające w naturalny sposób stan obecny, jest dołączenie przyjętego sposobu kodowania jako nowej strony kodowej. Rozwiązanie to wymaga akceptacji i współpracy ze strony producentów

oprogramowania, którzy - jak się wydaje - są pod tym względem mało elastyczni. Być może wyjątek stanowi tutaj Digital Research, która to firma nie sprzedaje systemu DR DOS bezpośrednim użytkownikom, lecz przedsiębiorstwom zajmującym się jego adaptacją i rozpowszechnianiem. DR DOS jako OEM product jest reklamowany jako system łatwo przystosowywalny do różnych języ ków naturalnych (w szczególność dopuszczona jest możliwość sto sowania kodów dwubajtowych) a adaptację ma ułatwiać specjalny Translation Kit. Należy jednak pa miętać, że standardowe programy obsługi stron kodowych współ pracują tylko z drukarkami produ kcji IBM lub z nimi kompatybilnymi, zatem stworzenie dodatkowych programów obsługi wydaj' się nie do uniknięcia.

Rozwiązaniem krańcowo odmiennym byłoby opracowanie zestawu programów obsługi klawiatury, ekranu i drukarki wykorzystujących samodzielnie opracowane fonty ekranowe i drukarkowe. Podejście to pozwala uniezależnić się od producentów oprogramowania i w naturalny sposób objąć obsługą bogatszy zestaw urządzeń (karta Hercules, drukarki Epson itp.). Należy jednak zdawać sobie sprawę, że podejście to ma również swoje ograniczenia. Przykładowo, system operacyjny jest wyposażony w algorytm przekształcania napisów (np. nazw zbiorów) zawierających małe litery na napisy złożone wyłącznie z dużych liter, przy czym algorytm ten jest - a przynajmniej powinien być - inny dla każdej strony kodowej. Jeżeli okaże się, że zmiana tego algorytmu jest z jakichś względów niemożliwa, trzeba będzie zrezygnować z polskich liter w nazwach zbiorów.

Oczywiście szybkość i powszechność akceptacji zaproponowanego standardu będzie zależeć właśnie od dostępności programów obsługi realizujących ten standard na powszechnie dostępnym sprzęcie. Trzeba tu z uznaniem odnotować m.in. działalność polskiej edycji „Computerworld"