Jeśli jesteś właścicielem tej strony, możesz wyłączyć reklamę poniżej zmieniając pakiet na PRO lub VIP w panelu naszego hostingu już od 4zł!

Str. główna i mapa serwisu

Konfiguracja czytnika Gravity

Program występuje w dwóch, nieco różniących się odmianach: 2.6 (build 2060), zwany Super Gravity, i 2.7 (build 2067), zwany MicroPlanet Gravity (lub w skrócie MPGravity). Konfiguracja obu programów w zakresie polskich liter jest identyczna. O ile nie zaznaczono inaczej, dalszy opis dotyczy wyłącznie programu MPGravity.

Spis treści:

  1. Ogólnie o programie – w tym o jego ograniczeniach i różnicach między wersjami
  2. Konfiguracja dla języka polskiego
    1. Wybór charsetu i kodowania transportowego
    2. Ustawienia fontów
    3. Ręczna zmiana charsetu wyświetlanej wiadomości
  3. Praca w środowisku wielojęzycznym
    1. Znaki narodowe i charsety
    2. Sprawdzanie ortografii
  4. Dodatek: Bugi powodujące kłopoty z ogonkami
  5. Dodatek: Inne bugi
  6. Dodatek: Niedogodności programu nie będące bugami
  7. Dodatek: Wyświetlenie dowolnego pola nagłówka czytanego listu
  8. Zmiana domyślnego widoku, rodzaju i kierunku sortowania
  9. Typy MIME – program podczas wysyłania załączników wymaga ręcznego zadeklarowania typu MIME załącznika
  10. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych)
  11. Linki

Taki znaczek: link do str. zewnętrznej przy odsyłaczu oznacza, że odsyłacz prowadzi do strony zewnętrznej.
A taki znaczek: link prowadzi do podstrony – że odsyłacz prowadzi do innej strony w tym serwisie.

1. Ogólnie o programie

Obie wersje programu mają bardzo ograniczoną obsługę języków, niestety jest to prawdopodobnie ograniczenie architektury programu (wygląda, że przynajmniej część modułów programu działa wewnętrznie w oparciu o strony kodowe, nie o unikod). Program wyświetla i pozwala wpisać wyłącznie znaki z bieżącej strony kodowej systemu operacyjnego (np. Windows w Polsce – strona kodowa Windows-1250), inne znaki wpisane w oknie kompozycji są przy wysyłaniu zamieniane na znaki zapytania, zaś inne znaki w czytanych postach są w miarę możliwości zastępowane znakami z US-ASCII z użyciem systemowej tablicy przekodowań. Super Gravity obsługuje teoretycznie większość charsetów ISO-8859-x, wersja MPGravity – teoretycznie wszystkie ISO-8859-x, KOI8-R i UTF-8, a dodatkowo potrafi czytać wszystkie charsety Windows i UTF-7, lecz jak już napisałem powyżej, obsługa ta jest uzależniona od strony kodowej systemu operacyjnego. W polskich warunkach w postach kodowanych UTF-8 wyświetlone będą tylko te znaki, które istnieją w stronie kodowej Windows-1250 – te, które istnieją w ISO-8859-2, plus niewielka ilość znaków specjalnych, takich jak znak Euro (€), znak copyrightu (©), „prawidłowe cudzysłowy”, półpauza – czyli kreseczka, znaki «cudzysłowu wewnętrznego», wielokropek (…) i znak promila (‰). Nie można więc wykorzystać głównej zalety unikodu, jaką jest możliwość stosowania dowolnych znaków w jednym tekście, bez zwracania uwagi na to, czy są one z jednej strony kodowej.

W związku z dopuszczeniem unikodu (w transformacji UTF-8) jako równorzędnego z ISO-8859-2 na grupach hierarchii pl.* (patrz strona poświecona usenetowi w Polsce link do str. zewnętrznej oraz posty: qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznej i dlptqd$csg$1@news.pse.pl link do str. zewnętrznej, oraz wcześniejsze: wątek cmrv87$ltf$3@debi.pekin.net.pl link do str. zewnętrznej, podwątek zaczynający się od 3dT2dac3kIpn6N34%chopin@akson.sgh.waw.pl link do str. zewnętrznej i post 5kT2kao5eI1s9N34.chopin@akson.sgh.waw.pl link do str. zewnętrznej) wydaje się, że z czasem to ograniczenie programu będzie coraz mocniej przemawiało przeciw jego szerszemu stosowaniu na polskich grupach dyskusyjnych, choć na razie ilość postów w UTF-8 zawierających znaki spoza Windows-1250 (strzałki, ułamki…) jest znikoma. Pamiętaj, że niedopuszczalne jest psucie przez Ciebie tych znaków w odpowiedziach na prawidłowe technicznie posty – Ty osobiście jesteś odpowiedzialny za wybór odpowiedniego czytnika, jego prawidłową konfigurację i ewentualne ręczne korygowanie jego błędów.

Super Gravity używa modułu sprawdzania pisowni Sentry Spelling Checker Engine wypuszczonego przez Wintertree Software Inc link do str. zewnętrznej. Nie ma słownika dla języka polskiego. MPGravity używa modułu MySpell, ale nie działa on prawidłowo ze słowami zawierającymi znaki spoza US-ASCII, które są na innych pozycjach w kodowaniu Windows i odpowiadającym mu ISO (np. były problemy z językiem polskim – moduł sprawdzania pisowni proponował zamianę np. „treść” na „tre¶ć”, analogiczne problemy wystąpiły ze słowami zawierającymi „ą” i „ź”).

Niewątpliwą zaletą programu jest obsługa załączników binarnych – z myślą o tym został on zaprojektowany w połowie lat 90. ubiegłego wieku. Doskonale nadaje się do przeglądania grup dyskusyjnych, na które wysyłane są zdjęcia (na przykład ztm.binaries – grupa ze zdjęciami pojazdów komunikacji miejskiej: autobusy, tramwaje, czasem pociągi podmiejskie link do str. zewnętrznej). Może współpracować z dowolną przeglądarką grafiki, mi najbardziej odpowiada użycie Gravity w połączeniu z przeglądarką Irfanview link do str. zewnętrznej. Gravity przez wiele lat nawet był programem komercyjnym, ale niekoniecznie musi być dobrym wyborem do regularnego uczestniczenia na polskojęzycznych tekstowych grupach dyskusyjnych.

Niewątpliwą wadą programu jest zaledwie częściowa obsługa kodowań, w tym uzależnienie jej od strony kodowej systemu operacyjnego. Program przy wysyłaniu zawsze deklaruje ustawiony charset (nawet gdy treść ani temat nie zawiera żadnych znaków spoza US-ASCII – wówczas zgodnie z zaleceniem RFC 2046 link do str. zewnętrznej p. 4.1.2 program powinien deklarować charset US-ASCII). Podobnie program ustawiony na wysyłanie w UTF-8 wyśle wszystko w tym kodowaniu, nawet gdyby było możliwe wysłać treść w kodowaniu 8-bitowym (np. ISO-8859-2). Zachowanie to jest niezgodne z zaleceniami dotyczącymi stosowania możliwie najwęższego charsetu, zawartymi w RFC2046 link do str. zewnętrznej p. 4.1.2 (ostatni akapit) i z opinią wyrażoną w poście qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznej, mówiącą, iż

[...] należy się stosować do zasady najmniejszego
niezbędnego charsetu - pisząc czysto po angielsku należy używać US-ASCII,
pisząc po polsku (czesku, słowacku itd.) - 8859-2, pisząc w języku nie
mającym odpowiedniego ISO 8859-N (albo naraz w kilku językach używających
różnych N) należy używać UTF-8.

Wyżej wymienione posty zostały napisane przez administratorów najważniejszych serwerów news w Polsce.

Przy wysyłaniu program nie ostrzega użytkownika, że w treści znajdują się znaki, które nie mogą zostać prawidłowo wysłane, czy to dlatego, że nie ma ich w wybranym kodowaniu, czy też dlatego, że program przez swoje wbudowane ograniczenia nie może ich obsłużyć. Obsługa znaków spoza US-ASCII jest ograniczona wyłącznie do tematu i treści (w przypadku nazwiska czy nicka nadawcy ujawnia się pewien bug). Obsługa UTF-8 przez MPGravity jest nieprawidłowa – program łamiąc linię tematu potrafi rozdzielić grupę zakodowanych oktetów reprezentującą jeden znak, co jest sprzeczne z RFC 2047 link do str. zewnętrznej p. 5.3, niektóre czytniki nie wyświetlają poprawnie tak przełamanego tematu. Wszystkie te niedogodności i bugi można obejść przez użycie konwertera MIME-Proxy link prowadzi do podstrony.

2. Konfiguracja dla języka polskiego

Opisane ustawienia zakładają, że podstawowym używanym charsetem będzie ISO-8859-2 (do niedawna charset jedyny obowiązujący na grupach dyskusyjnych hierarchii pl, obecnie dużo popularniejszy od drugiego legalnego charsetu, którym jest UTF-8).

2.1 Wybór charsetu i kodowania transportowego

Konfiguracja właściwego charsetu i kodowania transportowego wygląda identycznie w obu wersjach programu i sprowadza się do zaledwie 3 kroków:

  1. Należy się upewnić, że system operacyjny ma wybrany odpowiedni locale. Niekoniecznie musi to być polski, może być dowolny używający strony kodowej Windows-1250 (czeski, słowacki, węgierski…),
  2. Otworzyć okno konfiguracji programu: ViewGlobal Options, ikona skrzyżowanego wkrętaka i klucza płaskiego, albo Ctrl+Shift+O,
  3. Na zakładce Encoding z listy charsetów wybrać ISO-8859-2 (strzałka nr 1) i zaznaczyć klatkę Send 8 bit characters (strzałka nr 2). Nie zaznaczać klatki Send 8 bit chars in header lines (strzałka nr 3):

    Zaznaczenie klatki obok strzałki 3 spowoduje wysyłanie znaków spoza US-ASCII w nagłówkach (temat, nadawca) w postaci 8-bitowej, co jest sprzeczne z normą internetową RFC 2822 link do str. zewnętrznej (p. 2.2 wyraźnie zabrania stosowania znaków 8-bitowych w nagłówkach) i spowoduje, że Twoje nagłówki będą nieczytelne dla innych, może z wyjątkiem użytkowników OE. Z kolei niezaznaczenie klatki obok strzałki 2 spowoduje wysyłanie znaków spoza US-ASCII w treści zakodowanych w Quoted-Printable, co samo w sobie nie jest nieprawidłowe ani tym bardziej technicznie niepoprawne, ale właściciel hierarchii pl. zaleca stosowanie kodowania 8-bit w treści postów link do str. zewnętrznej.

2.2 Ustawienia fontów

Aby móc poprawnie zobaczyć ascii-arty, formatowanie i zaznaczenia tekstu, należy ustawić czcionki o stałej szerokości co najmniej dla czytanej treści: zaznaczyć Body – strzałka nr 1, a potem kliknąć na Font/Color obok – strzałka nr 2, oraz cytowanego tekstu w czytanym artykule – strzałka nr 3:

W obu miejscach domyślnie ustawiony jest font MS Sans Serif (proporcjonalny).

Font o stałej szerokości dla okna kompozycji ustawia się na zakładce Posting (przycisk Choose Font) – tam na szczęście domyślnie ustawiony jest font o stałej szerokości i nie ma możliwości wyboru innego typu czcionki:

W oknach dialogowych wyboru czcionki są dostępne listy przewijane skryptu czcionki, ale wybór skryptu nie działa (zawsze wybierany jest skrypt właściwy dla locale systemu.

2.3 Ręczna zmiana charsetu wyświetlanej wiadomości

Funkcja ta jest dostępna tylko w MPGravity. Gdy w wyświetlanej wiadomości widzimy krzaki (bo jakiś opslukowiec zaniedbał prawidłowej konfiguracji swojego czytnika), należy wejść w Article ⇒ Character Coding…

i w nowo otwartym oknie z listy wybrać żądany charset (najczęściej na grupach pl. będzie to ISO-8859-2). Niestety, nie ma możliwości dodania przełącznika charsetu do żadnego paska narzędziowego. Opslukowcom wysyłającym niepoprawne artykuły warto zwracać uwagę i odsyłać do stron o prawidłowej konfiguracji ich programów, gdyż przynajmniej niektórzy z nich nie zdają sobie sprawy z błędnej konfiguracji i kłopotów, jakie stwarzają innym.

3. Praca w środowisku wielojęzycznym

3.1 Znaki narodowe i charsety

Możliwe jest używanie tego programu wyłącznie z językami, które korzystają z tej samej 8-bitowej strony kodowej, na którą ustawiony jest komputer użytkownika. Na przykład na komputerze z locale ustawionym na polski, co odpowiada stronie kodowej Windows-1250, można używać programu do korzystania z grup dyskusyjnych, na których pisze się w jednym z języków, których znaki zawarte są w stronie kodowej Windows-1250. Będą to języki krajów Europy Środkowej i Wschodniej używające alfabetu łacińskiego i dodatkowo język angielski i niemiecki. Użycie programu z innymi językami wymaga zmiany systemowego locale lub instalacji i wyboru czcionek z odpowiednim kodowaniem, choć ten sposób nie zawsze działa. Nie można zmieniać wrotki (mieć kilku wrotek w kilku językach), ale można mieć różne podpisy w różnych językach. Na podstronie link prowadzi do podstrony możesz znaleźć wszystkie języki, które mogą być zakodowane w tym samym kodowaniu Windows, którego używasz na swoim komputerze (np. ustawienie polskie to Windows-1250, zaś wszystkie angielskie, francuskie i niemieckie to Windows-1252) – to będą języki, które możesz obsłużyć programem na raz. Nazwa autora, wrotka i podpis mogą zawierać tylko te znaki spoza US-ASCII, które istnieją w systemowej stronie kodowej.

3.2 Sprawdzanie ortografii w innych językach

Super Gravity używa modułu sprawdzania pisowni Sentry Spelling Checker Engine wypuszczonego przez Wintertree Software Inc. link do str. zewnętrznej. W pakiecie instalacyjnym zawarty jest słownik języka angielskiego, od producenta można kupić dodatkowe słowniki link do str. zewnętrznej dla 10 zachodnioeuropejskich języków. MPGravity używa modułu MySpell link do str. zewnętrznej i w pakiecie instalacyjnym zawarty jest słownik amerykańskiego angielskiego. Pliki słowników innych języków należy umieścić w katalogu gravity\spell, a następnie w opcjach, na zakładce Spelling, wybrać te pliki. Należy pamiętać o tym, by w górnym oknie wskazać plik zbioru słów (strzałka nr 1), a w dolnym – plik reguł odmiany (strzałka nr 2):

Moduł sprawdzania pisowni MPGravity nie działa do końca prawidłowo ze słowami zawierającymi znaki spoza US-ASCII, które są na innych pozycjach w kodowaniu Windows i odpowiadającym mu ISO (np. były problemy ze słownikiem języka polskiego proponującym zamianę np. „treść” na „tre¶ć”, analogiczne problemy wystąpiły ze słowami zawierającymi „ą” i „ź”, można oczekiwać analogicznych problemów z innymi literami i charsetami, np. KOI8-R i ISO-8859-16), ale w przypadku słów ze znakami, które nie różnią się położeniem w danym charsecie Windows i odpowiadającym mu charsecie ISO, np. wszystkie znaki z ISO-8859-1, wydaje się działać poprawnie (np. działał poprawnie ze słownikiem języka niemieckiego). Brakuje też mu kilku udogodnień: nie pokazuje kontekstu, w jakim znalazł nierozpoznane słowo, nie ma opcji ignorowania ani poprawienia wszystkich takich znalezionych słów, zaś własny słownik użytkownika (zwany Ignore list) jest jeden globalny, a nie, jak można by oczekiwać, osobno dla każdego języka. Po zmianie słownika może być konieczny restart programu (sic!).

4. Dodatek: Bugi powodujące kłopoty z ogonkami

1. Bardzo niepełna obsługa kodowań
Opis buga: Program ma możliwość wysyłania postów w wielu charsetach, ale w rzeczywistości obsługuje tylko znaki z systemowej strony kodowej. Przy wyświetlaniu znaków spoza systemowej strony kodowej program usiłuje je pokazać z użyciem systemowej tablicy przekodowań, ale wysyła je jako znaki zapytania.
Metoda obejścia: Brak (wygląda to na ograniczenie wewnętrznej struktury programu).

2. Błędna obsługa znaków spoza US-ASCII we From:
Opis buga: Gdy nazwa użytkownika lub jego nick zawiera znaki spoza US-ASCII, a przy kompozycji otworzy się okno dodawania własnych nagłówków (Advanced fields…) i wstawi tam jakieś dodatkowe informacje, znaki wymagające przekodowania między charsetami zostają popsute. W przypadku języka polskiego są to małe i wielkie litery ą, ś i ź, które następnie nie zostaną przekodowane z Windows-1250 na ISO-8859-2, ale wysłane z deklaracją ISO. Inne litery w ISO-8859-2, na które wpływa ten bug, to Ľ, ľ, Š, š, Ť, ť, Ž i ž. Jeżeli chodzi o inne kodowania rodziny ISO, to ten bug jest najbardziej dokuczliwy przy stosowaniu kodowania ISO-8859-15, ISO-8859-16 i ISO-8859-4, inne znane mi charsety (ISO-8859-1, ISO-8859-7 i ISO-8859-13) różnią się od odpowiednich charsetów Windows tylko pojedynczymi znakami, których normalnie nie używa się w nazwiskach. Zestawienia znaków różniących się między odpowiednimi charsetami: ISO-8859-2 a Windows-1250 link prowadzi do podstrony, ISO-8859-7 a Windows-1253 link prowadzi do podstrony, ISO-8859-13 a Windows-1257 link prowadzi do podstrony, ISO-8859-15 a Windows-1252 link prowadzi do podstrony (na tej stronie jest też o ISO-8859-1, który od Windows-1252 różni się jedynie brakiem pewnych znaków, ale w zakresie wspólnym znaki położone są identycznie w obu charsetach), ISO-8859-16 a Windows-1250 i Windows-1252 link prowadzi do podstrony.
Metoda obejścia: Gdy otworzy się to okno, należy w pokazującym się tam nazwisku czy nicku użytkownika ręcznie poprawić ww. znaki na poprawne. Spośród polskich liter, Ą będzie pokazane jako Ľ, ą – jako š, pozostałe cztery litery niestety jako znaki zapytania. Spośród niepolskich: Ľ jako ź, ľ jako ž, reszta jako znaki zapytania. Akcent ˇ jako Ą. Inny sposób, dostępny bardziej zaawansowanym użytkownikom, to wpisanie już odpowiednio zakodowanej do Quoted-Printable i w docelowym charsecie (np. w ISO-8859-2) nazwy użytkownika w rejestrze w kluczu HKCU | Software | Microplanet | Gravity | Servers | ServerX, w ciągu o nazwie FullName, wówczas mimo otwarcia tego okna, wprowadzenia w nim dodatkowych wpisów i zatwierdzenia zmian znaki te nie ulegną zepsuciu. Należy pamiętać o tym, że zakodowany ciąg nie może przekraczać 76 znaków – przed wysłaniem koniecznie trzeba jeden raz otworzyć okno Advanced fields…, ewentualnie dopisać jakieś nagłówki i kliknąć OK. Każde następne otwarcie tego okna i kliknięcie w nim OK spowoduje zepsucie wspomnianych liter. Tradycyjnie przed grzebaniem w rejestrze mocno zalecam zrobienie kopii zapasowej rejestru i upewnienie się, że w razie czego będzie się umiało odtworzyć rejestr z kopii zapasowej. Bug zgłoszony autorom projektu (bug 1321238 link do str. zewnętrznej).
UWAGA: Super Gravity cechuje się dodatkowym bugiem – znaki spoza US-ASCII we From są wysyłane bez przekodowania charsetu (np. z Windows-1250 do ISO-8859-2), choć z wybraną deklaracją ISO; metoda obejścia polega na tym, że nazwa użytkownika, którą się wpisuje podczas konfiguracji serwera, musi być zakodowana w docelowym kodowaniu (np. ISO-8859-2). Jeżeli wykorzystuje się rozwiązanie polegające na wpisaniu zakodowanej nazwy użytkownika w wyżej wspomnianym kluczu rejestru, to należy pamiętać, że po otwarciu okna Advanced fields… znaki spoza US-ASCII pokazane w kodowaniu Windows należy zastąpić znakami w docelowym kodowaniu, gdyż w tej wersji programu znaki te są odkodowywane przed pokazaniem ich w tym oknie.

3. Wysyłanie w niektórych nagłówkach znaków 8-bitowych
Opis buga: Znaki spoza US-ASCII w nagłówkach innych niż Temat i Nadawca, czyli w Organization, Keywords, Summary (pozostałych też, ale w nich normalnie nie używa się znaków spoza US-ASCII) i własnych nagłówkach (X-nagłówkach) są wysyłane bez zakodowania.
Metoda obejścia: Nie używać w tych nagłówkach znaków spoza US-ASCII lub wstawiać od razu poprawnie zakodowane ciągi (muszą one być już zakodowane do Quoted Printable, a znaki spoza US-ASCII muszą być w nich od razu przekodowane do docelowego charsetu). Niestety, metoda ta ma ograniczoną użyteczność, gdyż program nie skróci żadnego z tych nagłówków przy wysyłce, a nie ma możliwości wstawienia znaku końca linii ani w żadnym polu okna edycji nagłówków Advanced fields…, ani do ciągu w rejestrze. Bug zgłoszony autorom projektu (bug 1321279 link do str. zewnętrznej). Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

4. Błąd w kodowaniu nagłówków przy użyciu unikodu
Opis buga: Gravity kodując nagłówek, np. temat listu, w UTF-8, nie przestrzega pewnego wymogu technicznego. W wyniku tego błędu w niektórych innych programach część danego nagłówka nie będzie wyświetlona lub będzie wyświetlona nieprawidłowo.
Metoda obejścia: Brak. Bug zgłoszony autorom projektu (bug 1321194 link do str. zewnętrznej).

5. Nierozpoznawanie deklaracji charsetu, gdy ma ona określoną składnię
Opis buga: Jeżeli w czytanym poście charset jest wzięty w znaki cudzysłowów i zaraz za nim występuje średnik, program wyświetli post w trybie raw, czyli bez żadnego przekodowania, z użyciem kodowania systemowego. Przykładem jest taka linia
Content-Type: text/plain; charset="iso-8859-2"; format=flowed
Metoda obejścia: Brak. Bug zgłoszony autorom projektu (bug 1321178 link do str. zewnętrznej). Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

6. Złe działanie modułu sprawdzania poprawności pisowni
Opis buga: Patrz p. 3.4 powyżej. Bug dotyczy tylko MPGravity.
Metoda obejścia: Brak. Bug zgłoszony autorom projektu (bug 1121725 link do str. zewnętrznej).

7. Podczas konfiguracji nowego serwera w pole Organization wstawiana jest twarda (niełamiąca) spacja
Opis buga: Jak w opisie. Znak ten nie dość, że powoduje wysyłanie postów z pozornie pustym nagłówkiem Organization, to jeszcze ma numer 160 (0xA0) i jako taki powinien zostać zakodowany, jest zaś wysyłany tak, jak jest.
Metoda obejścia: Ręcznie usuwać podczas konfiguracji. Bug zgłoszony autorom projektu (bug 1321354 link do str. zewnętrznej).

8. Możliwość wysłania w temacie posta znaków 8-bitowych
Opis buga: Jeżeli program został skonfigurowany, by w przypadku wysyłąnia posta z załącznikiem dodawać do tematu nazwę załączonego pliku, a w tej nazwie występują znaki spoza US-ASCII, znaki te zostaną wysłane w postaci 8-bitowej, co jest wbrew RFC 2822 link do str. zewnętrznej p. 2.2.
Metoda obejścia: Z uwagi na możliwe problemy z obecnością znaków spoza US-ASCII w nazwach plików najlepiej i najbezpieczniej jest nie stosować takich znakó w nazwach załączników. Patrz też p. 10.

Sądząc po wieku innych bugów – najstarszy z grudnia 2003 r. – i fakcie, że do tej pory żaden z nich nie został nawet nikomu przypisany, nie robiłbym sobie zbyt dużej nadziei na usunięcie ich.

5. Dodatek: Inne bugi

1. Pseudowątkowanie po temacie
Opis problemu: Czytnik łączy w wątki posty, które mają identyczne tematy, choć ich pola References wyraźnie wskazują, że nie pochodzą z jednego wątku.
Metoda obejścia: W rejestrze w kluczu HKEY_CURRENT_USER|Software|MicroPlanet|Gravity|System znaleźć wpis SubjMatch i zmienić jego wartość na jakąś bardzo dużą liczbę.

2. Brak możliwości wyboru typu MIME image/png
Opis problemu: W internecie każdy rodzaj pliku ma skojarzony z nim typ MIME. Normy internetowe mówią, że programy obsługujące pliki z internetu muszą stosować się do ich typu MIME, a nie do ich rozszerzeń. Grafika PNG o typowym rozszerzeniu .png ma typ MIME image/png. Użycie niewłaściwego typu pliku MIME często kończy się niewłaściwym pokazaniem takiego pliku lub brakiem możliwości jego wyświetlenia.
Metoda obejścia: 1. Postępować zgodnie z instrukcją, albo 2. wysyłać z deklaracją ustawioną na Other, co spowoduje wysłanie załącznika bez deklaracji MIME, co jest mniejszym złem od deklaracji nieprawidłowej.

6. Dodatek: Niedogodności programu nie będące bugami

1. Brak możliwości konfiguracji domyślnego charsetu do wyświetlania postów, które nie zawierają tej deklaracji (głównie pochodzące z nieskonfigurowanych OE)
Opis problemu: Treść takiej wiadomości będzie wyświetlona tak, jakby miała deklarację ISO-8859-1. Zgodnie z RFC 2046 link do str. zewnętrznej p. 4.1.2. brak deklaracji jest tożsamy z deklaracją US-ASCII i o ile można dyskutować nad sensownością domyślności ISO-8859-1, nie jest to zachowanie technicznie niepoprawne.
Metoda obejścia: Nakłaniać problematycznych opslukowców do poprawienia konfiguracji, opornych tępić. Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

2. Brak umiejętności automatycznego doboru optymalnego (najwęższego możliwego) charsetu
Opis problemu: RFC 2046 link do str. zewnętrznej p. 4.1.2. zaleca stosowanie najwęższego możliwego charsetu, np. by używać deklaracji US-ASCII dla postów nie zawierających znaków spoza US-ASCII. Przyjęte też jest nieużywanie unikodu, gdy treść może być zakodowana w jednym z 8-bitowych charsetów ISO-8859-x. Gravity zawsze wysyła w ustawionym w opcjach charsecie, nawet gdy treść nie zawiera znaków wymagających tego kodowania – na przykład mimo braku w treści znaków spoza US-ASCII Gravity zawsze zadeklaruje kodowanie ISO (albo KOI8-R albo UTF-8), analogicznie MPGravity ustawiony na używanie UTF-8 zawsze użyje tego kodowania, nawet gdy zestaw użytych znaków pozwala na użycie jednego z kodowań ISO, nie mówiąc o US-ASCII. Gravity w ogóle nie umożliwia zadeklarowania charsetu US-ASCII.
Metoda obejścia: Brak, pozostaje ręczna zmiana charsetu w opcjach. Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

3. Funkcja ROT13 przekształca całość tekstu w oknie
Opis problemu: Nie można zaznaczyć tylko zakodowanego fragmentu i go odkodować, zmianie ulega cały tekst wyświetlony w danym oknie.
Metoda obejścia: Korzystać z zewnętrznej odkodowywaczki. Funkcję taką ma na przykład Notesik link do str. zewnętrznej, albo można posłużyć się odkodowywaczką na stronie evil.pl link do str. zewnętrznej.

4. Podczas tworzenia postu z załącznikiem program wymaga ręcznego wyboru typu MIME załącznika w oknie dialogowym wyboru załącznika
Opis problemu: W internecie każdy rodzaj pliku ma skojarzony z nim typ MIME. Normy internetowe mówią, że programy obsługujące pliki z internetu muszą stosować się do ich typu MIME, a nie do ich rozszerzeń. Na przykład zdjęcia w formacie JPEG (typowe rozszerzenie to .jpg i .jpeg) mają typ MIME image/jpeg, grafika PNG (typowe rozszerzenie: .png) – image/png, a plik dźwiękowy typu wave o typowym rozszerzeniu .wav – audio/wav. Normalnie każdy dobry program potrafi sam dobrać właściwy typ MIME dla pliku. Użycie niewłaściwego typu pliku MIME często kończy się niewłaściwym pokazaniem takiego pliku lub brakiem możliwości jego wyświetlenia. Patrz prawidłowe typy MIME w p-cie 9.
Metoda obejścia: Brak. Można w opcjach ustawić jako domyślny typ MIME Other, co spowoduje domyślne wysyłanie załączników bez deklaracji MIME, dzięki czemu nie zostanie wysłany post z nieprawidłową deklaracja MIME dla załącznika (załączników). Należy pamiętać, że jest to tylko mniejsze zło i starać się nie zapomnieć wybrać odpowiedniego typu MIME.

7. Dodatek: Wyświetlenie dowolnego pola nagłówka czytanego listu

Po wejściu w opcje (Ctrl+Shift+O) należy przejść na zakładkę Article Layout:

Tam w lewym oknie (oznaczonym 1) zaznaczyć pole nagłówka, jakie chce się mieć wyświetlone, i kliknąć na Add (czerwona strzałka). Można ewentualnie zmienić relatywną pozycję tego nagłówka przyciskami Move Up lub Move Down. Na przykład aby widzieć, jakiego kodowania używa czytany właśnie list, można dodać wyświetlanie pola nagłówka Content-Type. Można zmienić krój, wygląd i kolor czcionki używanej do wyświetlenia danego pola nagłówka klikając na Font/Color… (czerwona strzałka nr 2). Kliknięcie na OK zachowuje zmiany.

8. Zmiana domyślnego widoku, rodzaju i kierunku sortowania

MPGravity domyślnie ustawiony jest na pokazywanie tylko nieprzeczytanych artykułów sortowanych w wątkach od najstarszego. Można to zmienić globalnie, a takze dodać dodatkowe filtry widoku, w oknie pokazującym się po kliknięciu na przycisk Filters. Można zastosować różne widoki osobno dla każdej grupy, wówczas po wejściu na daną grupę i wybraniu odpowiedniego widoku z listy rozwijanej kliknąć na znaczek zaraz na prawo od listy widoków:

Edytując istniejące i nowo dodane filtry widoków można też zmienić domyślny rodzaj i kierunek sortowania postów korzystając z przejrzystego i intuicyjnego okna dialogowego opcji. Wystarczy pamietać, że sortowanie ascending to sortowanie od najstarszego do najnowszego, zaś descending – od najnowszego do najstarszego.

9. Typy MIME

Program wymaga ręcznego deklarowania typu MIME dla każdego załącznika. Poniżej przedstawiam tabelkę z typami MIME, które obsługuje program, i typowymi rozszerzeniami, jakie mają pliki danego typu MIME:

Typ MIMETypowe rozszerzenia
Typy MIME dostępne w programie
Application/Octet-stream.bin .dat .dll .exe
Application/PostScript.ps
Application/rtf.rtf
Application/X-zip-compressed.zip
Application/Zip.zip
Audio/Basic.snd .au
Audio/X-wav.wav
Image/GIF.gif
Image/JPEG.jpg .jpeg .jpe
Image/TIFF.tif .tiff
Other[brak deklaracji]
Text/Plain.txt .inf .ini
Text/Richtext.rtf
Video/AVI.avi
Video/MPEG.mpg .mpeg .mpe
Video/Quicktime.mov .qt
Video/X-msvideo.avi
Typy MIME innych często spotykanych typów plików
Application/msword.doc
Application/pdf.pdf
Application/rar.rar .rNN NN – numer
Application/x-compress.zip .rar .cab .7z… dowolne archiwum skompresowane
Application/x-shockwave-flash.swf
Audio/midi.mid .midi
Audio/mpeg.mp3
Image/png.png
Text/html.htm .html
Message/rfc822.eml

10. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych)

Oprócz oczywistej sytuacji, gdy wiemy, że odbiorcy życzą sobie lub nie będą w stanie odczytać polskich (czy innych) liter – np. grupa dyskusyjna ma w swoim FAQ-u zakaz używania znaków narodowych – bardzo zalecane jest nieużywanie żadnych takich znaków w nazwach załączników. Spowodowane jest to tym, że znaki spoza US-ASCII mogą być zakodowane na jeden z trzech sposobów:

Aby odbiorca mógł otworzyć załącznik, jego program musi obsługiwać użytą metodę kodowania. Brak obsługi danego sposobu kodowania u odbiorcy skutkuje zmianą nazwy załącznika – gdy list zawiera kilka załączników z opisem ich zawartości w treści, jest to bardzo uciążliwe. Innym problemem jest to, że oprócz zmiany nazwy pliku często zmieniane jest też rozszerzenie (na nic nie mówiące .dat, .att lub .bin), z czym mniej zaawansowany odbiorca sobie nie poradzi. Dodatkowo, nawet gdy program odbiorcy obsługuje metodę kodowania użytą przez nadawcę, w przypadku metod RFC dodatkowo jego system operacyjny i aplikacje używane do otwierania tego typu plików muszą obsługiwać znaki użyte w nazwie. Z kolei w przypadku załączników wysłanych bez kodowania nazwy (tryb Raw) znaki spoza US-ASCII w nazwie mogą zostać wyświetlone w przypadkowym kodowaniu (np. kodowaniu systemowym lub ISO-8859-1), skutkiem czego w nazwie będą krzaki. Nie istnieje proste, w pełni skuteczne rozwiązanie powyższych ograniczeń, jedyny sposób, który na 100% zadziała u wszystkich, to użycie wyłącznie znaków US-ASCII w nazwie załącznika.

Należy również pamiętać, że niektóre formaty plików co prawda pozwalają na umieszczenie w treści znaków narodowych, ale nie przenoszą informacji o użytym kodowaniu, przez co w wypadku przesłania takiego pliku jako załącznik u odbiorcy znaki narodowe mogą się nie wyświetlić prawidłowo. Najbardziej powszechny przykład to pliki tekstowe (o rozszerzeniu .txt). W typowym systemie Windows plik taki otwierany jest w systemowym Notatniku, w którym zawsze używane jest kodowanie systemowe i nie ma żadnej możliwości zmiany kodowania treści. Znaki narodowe będą pokazane prawidłowo tylko w sytuacji, gdy komputer odbiorcy używa tego samego kodowania systemowego, którego używa komputer nadawcy. Kodowanie systemowe zależy od locale systemowego (w przypadku korespondencji z osobami przebywającymi w innych krajach należy założyć, że locale nadawcy i odbiorcy będzie się różnić) oraz używanego systemu operacyjnego. Przed przesłaniem takiego załącznika należy się upewnić, że odbiorca będzie mógł zobaczyć znaki narodowe w treści.

Linki

Rozwiązania przetestowane na programach Super Gravity 2.6 i MPGravity 2.7 pod Windows 2000 SP4 English z locale ustawionym na polski.

licznik