This file belongs to the CEP package | Ten plik nale/zy do pakietu CEP This package is public domain | Pakiet stanowi dobro powszechne For more info see `0CEP_LIC.ENG' | Wi/ecej informacji w ,,0CEP_LIC.POL'' =========================================================================== ,,CEPCOP_P.INF'' -- DOKUMENTACJA POLSKA Osoby zajmuj/ace si/e obr/obk/a danych graficznych od zawsze maj/a k/lopoty z ogromnymi i wci/a/z rosn/acymi plikami. Na przyk/lad grafika formatu A4 przeskanowana w rozdzielczo/sci 300 DPI sk/lada si/e z ok. 8 700 000 pikseli. Je/sli jest to kolorowa mapa bitowa, w kt/orej ka/zdy piksel opisany jest czterema bajtami (CMYK), to zajmuje ona na dysku w przybli/zeniu 35 MB. Niestety, to dopiero pocz/atek. U/zytkownik TeX-a nie mo/ze u/zywa/c danych w postaci binarnej (nie pozwala na to niestety DVIPS). Nasz biedny TeX-nik konwertuje wi/ec grafik/e do postaci szesnastkowego EPS, co dwukrotnie zwi/eksza zajmowane przez ni/a miejsce. Pami/etajmy r/ownie/z, /ze trzeba zarezerwowa/c sobie co najmniej jeszcze raz tyle miejsca na dysku, aby mia/l gdzie powsta/c po przetworzeniu dokumentu TeX-em i DVIPS-em wynikowy plik .PS zawieraj/acy ca/l/a informacj/e graficzn/a. Okazuje si/e wi/ec, /ze na ka/zd/a stron/e A4 potrzebujemy 140 MB na dysku. A dyski niestety kosztuj/a... Problem ten jest znany ju/z od dawna. Firma Adobe, tworz/ac wiele lat temu PostScript, najpopularniejszy j/ezyk opisu strony, zawar/la w specyfikacji poziomu drugiego (Level 2) obiekty zwane filtrami, umo/zliwiaj/ace kompresj/e danych. Mo/zemy wi/ec zamiast kodowania szesnastkowego zastosowa/c kodowanie ASCII85 (podobne do tego z UNIX-owego uuencode). Mamy te/z dost/ep do kompresji algorytmem ,,run length'', algorytmem LZW, stosowanym w plikach JPEG algorytmem DCT, a tak/ze kilku innych. Nasuwa si/e pytanie, dlaczego w codziennej praktyce nie stosuje si/e tych metod kompresji? Ot/o/z niewiele program/ow -- nie wiedzie/c czemu -- potrafi zapisa/c grafik/e w postaci skompresowanych plik/ow EPS, a do tego s/a to programy ma/lo popularne. Poni/zszy pakiet w pewnym zakresie rozwi/azuje ten problem. Umo/zliwia on kompresowanie najcz/e/sciej spotykanych, nieskompresowanych PostScript-owych plik/ow graficznych. Niestety, w trakcie pracy nad programem okaza/lo si/e, /ze problem jest bardziej skomplikowany, ni/z si/e pocz/atkowo wydawa/lo. Na przyk/lad nie da si/e wybra/c jednego, najlepszego algorytmu kompresji i zawsze go stosowa/c. Wyb/or ten musi zale/ze/c od rodzaju kompresowanych danych, ich postaci, a tak/ze spodziewanego zastosowania. Z tego w/la/snie powodu pakiet sk/lada si/e z a/z dw/och zestaw/ow program/ow, z kt/orych ka/zdy posiada kilka opcji, umo/zliwiaj/acych pewne sterowanie procesem kompresji. * * * Nasz pakiet sk/lada si/e z dw/och par program/ow AWK-owych: CEP.AWK-UNCEP.AWK oraz COP.AWK-UNCOP.AWK. CEP.AWK i COP.AWK tworz/a na podstawie analizy danych wej/sciowych program PostScript-owy, kt/ory przetwarzany przez Ghostscript-a, dokonuje w/la/sciwej kompresji danych i tworzy plik wynikowy. UNCEP.AWK i UNCOP.AWK wykonuj/a (u/zywaj/ac zbli/zonej metody) proces odwrotny, to znaczy dekompresj/e danych do postaci wej/sciowej. CEP zosta/l stworzony do kompresji cz/esto spotykanych plik/ow EPS zawieraj/acych pojedyncz/a map/e bitow/a zakodowan/a szesnastkowo; COP potrafi skompresowa/c dowolne dane PostScript-owe. Powstaje pytanie, po co u/zywa/c CEP-a, je/zeli COP potrafi skompresowa/c dowolny plik PostScript-owy. Odpowied/x jest bardzo prosta -- CEP wie, jakich danych si/e spodziewa/c, i w zwi/azku z tym potrafi je spakowa/c du/zo efektywniej. Poprawa efektywno/sci wynika z dw/och czynnik/ow. Po pierwsze CEP spodziewa si/e danych szesnastkowych, czyli przyjmuje, /ze dwa znaki kodu opisuj/a jeden bajt mapy bitowej (co ju/z powoduje zwi/ekszenie upakowania informacji). Po drugie mapy bitowe maj/a najcz/e/sciej zdecydowanie bardziej regularn/a (redundantn/a) struktur/e ni/z przeci/etny kod PostScript-owy. Wynika z tego, /ze w przypadku map bitowych nawet prostsze algorytmy kompresji mog/a da/c bardzo dobre rezultaty. Z naszych eksperyment/ow wynika, /ze przy dobrych danych wej/sciowych (zrzuty grafiki z ekranu) /latwo jest osi/agn/a/c nawet dwudziestokrotn/a kompresj/e. Niestety, w niekt/orych przypadkach /zadna metoda kompresji nie daje efekt/ow. W takiej sytuacji zawsze mo/zemy zastosowa/c filtr ASCII85, kt/ory zmniejszy obj/eto/s/c mapy bitowej zakodowanej szesnastkowo o oko/lo 35%. Poni/zej kr/otko opisujemy dzia/lanie CEP-a i COP-a. Jak na razie, pakiet ten dzia/la tylko w systemie MS DOS, cho/c mamy nadziej/e, /ze uda si/e go /latwo przenie/s/c na inne platformy, tam gdzie s/a dost/epne GAWK i Ghostscript. W tej wersji zastosowali/smy implementacj/e AWK-a stworzon/a w ramach inicjatywy GNU: GAWK32.EXE oraz wersj/e Ghostscript-a dla systemu DOS: GS386.EXE. Do test/ow pakietu u/zywali/smy kilku wersji Ghostscripta i GAWK-a. Aktualnie u/zywamy ju/z Ghostscripta w wersji 5.10 oraz GAWK 3.0.3. (w wersji 32-bitowej -- GAWK32.EXE) i nie zauwa/zyli/smy /zadnych problem/ow. ========================================================================== C E P i U N C E P ========================================================================== W sk/lad podpakietu CEP wchodz/a DOS-owe pliki wsadowe CEP.BAT i UNCEP.BAT oraz programy AWK-owe CEP.AWK i UNCEP.AWK. Po wywo/laniu pliku wsadowego najpierw uruchamiany jest AWK, kt/ory przegl/ada dane wej/sciowe, stara si/e znale/x/c w nich map/e bitow/a zakodowan/a szesnastkowo i tworzy odpowiedni program PostScript-owy. Nast/epnie zostaje uruchomiony Ghostscript, kt/ory wykonuj/ac przygotowany w poprzednim kroku program, dokonuje w/la/sciwego przetwarzania danych. Przepisuje on te/z oryginaln/a preambu/l/e PostScript-ow/a dokonuj/ac w niej tylko kilku zmian; /zadne komentarze DSC nie ulegaj/a zmianie. Je/zeli program nie znajdzie w pliku mapy bitowej albo w trakcie analizy struktury pliku powstaj/a jakie/s problemy, CEP poddaje si/e i nie tworzy wynikowego EPS-a. Przed skasowaniem oryginalnej wersji zalecamy sprawdzenie, czy powsta/ly plik jest prawid/lowy. W niekt/orych (rzadkich) przypadkach CEP mo/ze b/l/ednie rozpozna/c map/e bitow/a. Czasami tak/ze b/l/edy Ghostscript-u mog/a powodowa/c powstanie uszkodzonego pliku, wi/ec lepiej zawsze obejrze/c go przed usuni/eciem /xr/od/la. CEP nie tworzy binarnych plik/ow wyj/sciowych, zawsze stosuje kodowanie ASCII85 lub szesnastkowe. Wynika to z naszego za/lo/zenia, /ze kompresowane CEP-em pliki b/ed/a u/zywane g/l/ownie w /srodowisku TeX-owym z DVIPS-em jako sterownikiem PostScript-owym. Niezale/znie od tego za/lo/zenia pliki CEP-owe mo/zna u/zywa/c w dowolnych systemach DTP, kt/ore wczytuj/a tak zwane ,,placeable EPS''. Niestety takie systemy najcz/e/sciej wymagaj/a EPS-/ow zawieraj/acych podgl/ad w postaci binarnego TIFF-a, kt/ory mo/ze zosta/c /xle przetworzony przez (G)AWK-a. UNCEP dekompresuje wszystkie pliki stworzone CEP-em pod warunkiem, /ze nie zosta/ly one w /zaden spos/ob zmienione. W skompresowanym pliku wyst/epuje specjalny komentarz ,,%UNCEPInfo:'', kt/ory zawiera informacje potrzebne do dekompresji. Jest on jednak bardzo czu/ly na budow/e pliku. Nawet tak nieznaczna zmiana jak dodanie (lub usuni/ecie) linii komentarza powoduje, /ze pliku nie daje si/e rozkompresowa/c. Trzeba te/z zwr/oci/c uwag/e na to, /ze podstaw/a kompresji jest tu przetwarzanie strumienia danych, czyli ci/agu liczb, a nie ci/agu znak/ow, co implikuje, /ze informacja o sposobie /lamania wierszy podczas czytania danych szesnastkowych jest tracona. W zwi/azku z tym UNCEP nie mo/ze wygenerowa/c pliku identycznego z wej/sciowym. Nie ma to /zadnego znaczenia dla PostScript-u, gdy/z jest on ca/lkowicie odporny na r/o/zne metody /lamania linii. Niestety niekt/ore programy ,,czytaj/ace'' pliki EPS z niezrozumia/lych przyczyn wymagaj/a /lamania linii wed/lug w/lasnych zasad. Tego typu programy (np. Aldus PhotoStyler) nie odczytaj/a zdekompresowanego pliku. U/ZYCIE CEP-a: cep.bat plik_wej/sciowy plik_wyj/sciowy [opcje] program rozpoznaje nast/epuj/ace opcje: 8 -- kodowanie ASCII85 (domy/slnie) h lub H -- kodowanie HEX (szesnastkowe) r lub R -- kompresja RLE (RunLength) (domy/slnie) l lub L -- kompresja LZW f lub F -- kompresja Flate (niestandardowa!) n lub N -- bez kompresji UWAGA: nazwa pliku wyj/sciowego musi by/c r/o/zna od nazwy pliku wej/sciowego U/ZYCIE UNCEP-a: uncep.bat plik_wej/sciowy plik_wyj/sciowy UWAGA: nazwa pliku wyj/sciowego musi by/c r/o/zna od nazwy pliku wej/sciowego, metoda dekompresji jest ustalana na podstawie pliku wej/sciowego. ========================================================================== C O P i U N C O P ========================================================================== W sk/lad podpakietu COP wchodz/a DOS-owe pliki wsadowe COP.BAT i UNCOP.BAT oraz programy AWK-owe COP.AWK i UNCOP.AWK. COP czyta i odpowiednio koduje zupe/lnie niemodyfikowany plik wej/sciowy. Nie przeprowadza on w/la/sciwie /zadnej analizy danych PostScript-owych. Jedynym wyj/atkiem jest pr/oba odnalezienia komentarza strukturalnego ,,%%BoundingBox:''. Je/sli pr/oba si/e powiedzie, jest on do/l/aczany do generowanej preambu/ly, w przeciwnym przypadku preambu/la nie zawiera komentarza ,,%%BoundingBox:''. Pliki wygenerowane przez COP-a s/a czytane przez ka/zdy interpreter PostScript-u Level 2. Przy wywo/laniu UNCOP-a nie trzeba ustawia/c /zadnych opcji, ustala on bowiem metod/e dekompresji na podstawie nag/l/owka pliku wej/sciowego. UNCOP, w przeciwie/nstwie do UNCEP-a, odtwarza dok/ladnie ka/zdy bit oryginalnego pliku. Niestety, z powodu b/l/ed/ow Ghostscript-a usuni/ecie pliku /xr/od/lowego przed sprawdzeniem, czy plik wynikowy jest prawid/lowy, mo/ze si/e sko/nczy/c niemi/l/a niespodziank/a. Dlatego przed skasowaniem /xr/ode/l zalecamy obejrzenie rozkompresowanego pliku pod Ghostscript-em. COP mo/ze by/c u/zywany do kompresowania wszelkich danych dla r/o/znych aplikacji, tak wi/ec zdecydowali/smy si/e w tym przypadku dopu/sci/c mo/zliwo/s/c kodowania binarnego. Kompresowane EPS-y niestety nie mog/a zawiera/c podgl/adu TIFF-owego, wykorzystywanego przez wiele program/ow przetwarzaj/acych grafik/e PostScript-ow/a. Plik wynikowy mo/ze by/c u/zywany jako tak zwany placeable EPS bez podgl/adu (preview), mo/zna te/z wczytywa/c skompresowane pliki jako tak zwany ,,PostScript interpreted''. Niekiedy si/e to udaje, ale nie nale/zy si/e dziwi/c, je/sli si/e to nie powiedzie -- interpretacja PostScript-u to naprawd/e trudne zadanie. U/ZYCIE COP-a: cop.bat plik_wej/sciowy plik_wyj/sciowy [opcje] program rozpoznaje nast/epuj/ace opcje: 8 -- kodowanie ASCII85 (domy/slnie) b lub B -- kodowanie binarne h lub H -- kodowanie HEX (szesnastkowe) r lub R -- kompresja RLE (RunLength) (domy/slnie) l lub L -- kompresja LZW f lub F -- kompresja Flate (niestandardowa!) n lub N -- bez kompresji UWAGA: nazwa pliku wyj/sciowego musi by/c r/o/zna od nazwy pliku wej/sciowego; kodowanie binarne polega na wy/l/aczeniu jakiegokolwiek kodowania. U/ZYCIE UNCOP-a: uncop.bat plik_wej/sciowy plik_wyj/sciowy UWAGA: nazwa pliku wyj/sciowego musi by/c r/o/zna od nazwy pliku wej/sciowego metoda dekompresji jest ustalana na podstawie pliku wej/sciowego ============================================================================= S T E R T A U W A G O C E P-ie I C O P-ie ============================================================================= Poni/zej podajemy rozwi/azania niekt/orych problem/ow napotkanych podczas tworzenia pakietu: * Nie ma prostej metody znajdowania zakodowanej szesnastkowo mapy bitowej w pliku EPS. Analiza semantyczna (do zrealizowania przez przedefiniowanie instrukcji ,,image'', ,,imagemask'' i ,,colorimage'') jest bardzo trudna do pe/lnej realizacji (parametry w postaci s/lownik/ow). Zdecydowali/smy si/e wi/ec na wyszukiwanie mapy bitowej oparte na analizie sk/ladni -- to z kolei wywo/la/lo k/lopoty z analiz/a napis/ow ,,add'' oraz ,,def'', kt/ore mog/a by/c zar/owno cz/e/sci/a mapy bitowej, jak i instrukcj/a PostScript-ow/a. * Nie da si/e tak/ze poda/c dok/ladnych wytycznych, kt/ora metoda kompresji b/edzie najlepsza dla konkretnych danych. Zwykle najlepsz/a metod/a kodowania jest ASCII85. Dla map bitowych (kompresowanych CEP-em) najcz/e/sciej wystarczy algorytm RLE, cho/c dla kolorowych rysunk/ow lepszy jest LZW. Najlepsze wyniki prawie zawsze daje metoda Flate. Jednak Flate, jak r/ownie/z LZW maj/a ograniczone zastosowania: (a) kompresja LZW zosta/la w wersjach 4.x Ghostscript-u wy/l/aczona z powodu nieszcz/esnego patentu (p. ,,S/lowniczek'' zamieszczony na ko/ncu). Aladdin zastosowa/l zast/epczo filtr koduj/acy zgodny z LZW, kt/ory niestety nie kompresuje danych (a nawet je zwi/eksza o 10%). Mo/zna u/zywa/c starszych wersji Ghostscript-a (maj/a one kilka b/l/ed/ow) lub skompilowa/c GS z filtrem LZW na w/lasn/a odpowiedzialno/s/c, ale... (b) kompresja Flate na razie niestety nie jest dost/epna w fotona/swietlarkach. Po prostu nie wchodzi w sk/lad specyfikacji PostScript-u Level 2. Jest nadzieja, /ze kiedy/s ten stan si/e zmieni i algorytm Flate (taki sam jak u/zywany w GZIP-ie) wejdzie do specyfikacji j/ezyka. W dokumentacji Ghostscript-a znajdujemy bowiem zdanie (w wolnym t/lumaczeniu): ,,Ghostscript obs/luguje r/ownie/z nieudokumentowane filtry FlateEncode and FlateDecode, zawarte w specyfikacji formatu PDF 1.2 oraz (przypuszczalnie) PostScript-u poziomu trzeciego'' Z naszych do/swiadcze/n wynika, /ze w przypadku skan/ow zdj/e/c najlepsze wyniki daje wy/l/aczenie kompresji i stosowanie tylko kodowania ASCII85. W przypadku takich danych /zadna bezstratna metoda kompresji nie jest w stanie nic zmieni/c (zdj/ecia zawieraj/a du/zo informacji szumowej). Nawet takie programy jak ARJ, ZIP czy LHARC nie dadz/a istotnie lepszych wynik/ow. Jedyn/a mo/zliwo/sci/a jest kompresja fotografii algorytmami stratnymi, takimi jak stosowany w plikach JPEG algorytm DCT. * Zgodnie z tym co powiedzieli/smy wy/zej, najcz/e/sciej polecane jest stosowanie kodowania ASCII85, niestety wywo/luje ono pewne problemy. Po pierwsze, aby omin/a/c b/l/ad Ghostscript-a (nadmiarowe znaczniki ko/nca danych), musieli/smy u/zy/c dodatkowego, pustego filtru NullEncode. Pojawia si/e niestety r/ownie/z drugi powa/zniejszy problem: dane zakodowane filtrem ASCII85 mog/a zawiera/c linie, kt/ore do/s/c skutecznie podszywaj/a si/e pod komentarze strukturalne. Mianowicie rozpoczynaj/a si/e od dw/och znak/ow procenta ,,%%'' lub od procenta i wykrzyknika ,,%!''. W tym kontek/scie wydaje si/e dziwne, /ze firma Adobe nie zdecydowa/la si/e na usuni/ecie procenta z zestawu znak/ow ASCII85. Niestety nie uczyni/la tego, wi/ec niekt/ore programy u/zywaj/ace plik/ow EPS, mog/a pr/obowa/c przetwarza/c linie zawieraj/ace takie ,,niby-komentarze''. DVIPS jest tego przyk/ladem -- standardowo usuwa linie komentarzy z wczytywanych plik/ow. Mo/zna zablokowa/c t/e funkcj/e (-K0), ale wtedy pozostaj/a r/ownie/z prawdziwe komentarze DSC, kt/ore mog/a powodowa/c b/l/edy w analizie dokumentu przez programy korzystaj/ace z konwencji DSC. * Przydatne mog/loby by/c w/l/aczenie do pakietu jeszcze kilku standardowych filtr/ow PostScript-u, na przyk/lad DCT oraz CCITTFax. Jednak filtry te wymagaj/a podania wielu parametr/ow wej/sciowych, wi/ec korzystanie z nich by/loby du/zo bardziej skomplikowane. Co wi/ecej, w/la/sciwie nie wiadomo, jak mo/zna ustala/c parametry kompresji DCT, nie maj/ac mo/zliwo/sci interakcyjnego korygowania efekt/ow. Na razie wi/ec nie oprogramowali/smy tych filtr/ow. W zamian przygotowujemy programik umo/zliwiaj/acy konwersj/e plik/ow JPEG (czyli bardzo mocno skompresowanych bitmap) do postaci PostScript-owych EPS-/ow (u/zywaj/acych filtra DCT). * W pakiecie CEP starali/smy si/e oszcz/ednie gospodarowa/c przestrzeni/a dyskow/a. W czasie pracy nie s/a tworzone /zadne du/ze pliki tymczasowe; w/la/sciwie do kompresji pliku potrzebne jest tyle wolnego miejsca na dysku, ile zajmuje plik wynikowy. * W czasie p/o/lrocznej eksploatacji pakietu okaza/lo si/e, /ze w wypadku niekt/orych komercyjnych urz/adze/n PostScript-owych zgodno/s/c z standardem PostScript Level 2 ko/nczy si/e na efektownych ulotkach i nalepce na obudowie. Cz/e/s/c na/swietlarek (zw/laszcza starszych) nie jest w stanie, mimo obietnic producent/ow, przetwarza/c poprawnie plik/ow *.ps zawieraj/acych operacje zwi/azane z obiektami typu filter. Jedyn/a metod/a sprawdzenia czy dana na/swietlarka prawid/lowo realizuje wymienione filtry jest niestety metoda pr/ob i b/l/ed/ow. W wypadku korzystania z na/swietlarki, kt/ora odmawia wsp/o/lpracy z pakietem CEP (czyli nie jest zgodna z PostScript-em Level 2), mo/zemy: (a) zmieni/c na/swietlarni/e, (b) wymusi/c na na/swietlarni zakup nowego urz/adzenia, lub ewentualnie uaktualnienia oprogramowania na/swietlarki (w przypadku RIP-a programowego) lub (c) zrezygnowa/c z u/zywania CEP-a. Pomocny mo/ze okaza/c si/e tu kr/otki plik PostScript-owy: %!PS-Adobe-2.0 EPSF-1.2 %%Pages: 1 %%BoundingBox: 0 0 540 150 %%EndComments /Helvetica 8 selectfont 90 rotate 1 2 moveto (*) {0 -10 rmoveto gsave show grestore} 255 string /Filter resourceforall showpage %%EOF Program ten spowoduje wypisanie listy filtr/ow obs/lugiwanych przez dany interpreter. Je/sli w czasie przetwarzania pojawia si/e b/l/ad (obs/luga w studiu graficznym twierdzi, /ze ,,plik si/e nie RIP-uje''), to najprawdopodobniej mamy do czynienia ze zbyt ubog/a wersj/a PostScript-u i musimy zrezygnowa/c z u/zywania CEP-a. Powy/zszy plik mo/zna albo bezpo/srednio wys/la/c na urz/adzenie PostScript-owe (na/swietlark/e, drukark/e), albo umie/sci/c w dokumencie TeX-owym jak zwyk/ly plik EPS. * B/l/edy i pu/lapki: (a) Poprzedzenie komendy ,,closefile'' teoretycznie nadmiarow/a komend/a ,,flushfile'' pozwala omin/a/c pluskw/e w GS 3.x (zjadanie ko/nc/owki pliku wyj/sciowego). (b) Dodatkowy, pusty filtr NullEncode pozwala nam omin/a/c (prawdopodobnie) pewn/a pluskw/e Ghostscript-a. Mianowicie filtr ASCII85 z wyj/sciem danych skierowanym do procedury cz/esto zapisuje w strumieniu wynikowym dodatkowe znaczniki ko/nca danych, czyli ~> (przy pewnych parametrach mo/ze zapisa/c ich tysi/ace). Skierowanie danych wyj/sciowych do procedury, zamiast bezpo/srednio do pliku niestety uniemo/zliwia stosowanie wcze/sniejszych ni/z 3.x wersji Ghostscript-a przy kodowaniu ASCII85. Na szcz/e/scie GS w wersji od 2.6x mo/ze by/c stosowany przynajmniej do kodowania szesnastkowego (HEX) -- ta wersja Ghostscript-a zawiera r/ownie/z ,,legaln/a'' kompresj/e LZW. (c) Procedura docelowa, o kt/orej pisali/smy w punkcie (b), zosta/la dodana, aby specjalnie zmodyfikowa/c wiersze, kt/ore mog/lyby by/c b/l/ednie zinterpretowane jako komentarze DSC. Specjalne traktowanie polega na prze/lamaniu wiersza po znaku procenta. Zabezpiecza to przed konsekwencjami cz/esto stosowanej, a w tym wypadku bardzo gro/xnej opcji DVIPS-a ,,usuwaj komentarze'' (-K1). (d) Dziwaczna sk/ladnia komendy ,,{2 2 .quit}'' zamiast formy ,,{2 .quit}'' zosta/la zastosowana z powodu b/l/edu w GS 3.5x, kt/ory wpada/l w niesko/nczon/a p/etl/e. Wewn/etrzn/a instrukcj/e Ghostscript-a ,,.quit'' wybrali/smy po to, by umo/zliwi/c obs/lug/e b/l/ed/ow na poziomie systemu operacyjnego. (e) W starszych wersja Ghostscript-a wyst/epuje jeszcze jeden dziwny b/l/ad, kt/orego nie uda/lo si/e nam omin/a/c. Mianowicie niekt/ore EPS-y s/a poprawnie kompresowane przez GS 2.6, ale ta sama wersja Ghostscript-a nie potrafi ich wy/swietli/c. Podobne objawy obserwowali/smy w przypadku innego pliku w wersji 3.51 Ghostscript-a. Oczywi/scie takie pliki daj/a si/e bez problemu odczyta/c w wy/zszych wersjach GS-a. Jak na razie Ghostscript w wersji 4.03 zachowuje si/e w spos/ob najbardziej stabilny, je/sli chodzi o filtrowanie danych. Gdyby nie /ow nieszcz/esny patent na LZW... No i mo/ze jeszcze k/lopoty z obs/lug/a pami/eci map bitowych (cache?). (f) Podsumowuj/ac, stanowczo polecamy stosowanie Ghostscript-a w wersji 4.x lub 5.x (ewentualnie z dokompilowanym algorytmem LZW) oraz GAWK-a w wersji 3.x. GS 4.x jest praktycznie pe/ln/a implementacj/a poziomu drugiego (Level 2) PostScript-u. GAWK 3.x umo/zliwia stosowanie wyra/ze/n regularnych jako separator/ow rekord/ow, co pozwala z kolei na obs/lugiwanie znak/ow ko/nca linii w spos/ob dok/ladnie zgodny z specyfikacj/a PostScript-u. Wersja 3.x GAWK-a jest tak/ze znacznie stabilniejsza od wersji poprzednich. ========================================================================== H I S T O R I A ========================================================================== CEP+UNCEP: 0.10 -- 16.03.97 -- pierwsza wersja 0.20 -- 05.04.97 -- usuni/eto kilka wykrytych b/l/ed/ow 0.30 -- 11.04.97 -- wprowadzono now/a metod/e modyfikacji preambu/ly (umo/zliwi/lo to przetwarzanie skomplikowanych prolog/ow), /l/aczenie plik/ow wyj/sciowych przeniesione na poziom PostScript-u (szybsze przetwarzania i mniejsze zu/zycie przestrzeni dyskowej) 0.35 -- 13.04.97 -- dodano komentarze (wersja dwuj/ezyczna) 0.40 -- 14.04.97 -- znacz/aco poprawiono szybko/s/c dzia/lania 0.50 -- 15.04.97 -- /la/ncuchy alokowane s/a statycznie, nie s/a tworzone pliki po/srednie (poprawa szybko/sci dzia/lania oraz zmniejszenie potrzebnej przestrzeni dyskowej) 0.60 -- 19.04.97 -- dodano obs/luge b/l/ed/ow w PostScript-cie, omini/eto kilka b/l/ed/ow GS-a 0.65 -- 20.04.97 -- dodano kod wyj/scia, powsta/la te/z dokumentacja 0.70 -- 21.04.97 -- pierwsza wersja UNCEP-a 0.75 -- 24.04.97 -- usuni/eto k/lopoty z r/o/znymi wersjami ko/nc/ow linii, oraz znacznikiem ko/nca danych szesnastkowych; zebrano i przet/lumaczono dokumentacj/e 1.00 -- 02.05.97 -- bezp/latne udost/epnienie (BachoTeX '97) 1.03 -- 07.01.98 -- uzupe/lnienie dokumentacji, poprawienie odporno/sci pakietu na egzotyczne dane (CEP.AWK) COP+UNCOP: 0.10 -- 06.04.97 -- pierwsza wersja 0.20 -- 12.04.97 -- budowa programu zosta/la ujednolicona z CEP-em, wstawiono "cvx exec" zamiast b/l/ednego "run" 0.25 -- 13.04.97 -- dodano komentarze (wersja dwuj/ezyczna) 0.30 -- 15.04.97 -- /la/ncuchy alokowane s/a statycznie (znacz/aca poprawa szybko/sci) 0.40 -- 19.04.97 -- dodano obs/luge b/l/ed/ow w PostScript-cie, omini/eto kilka b/l/ed/ow GS-a 0.45 -- 20.04.97 -- dodano kod wyj/scia, powsta/la dokumentacja 0.50 -- 24.04.97 -- usuni/eto k/lopoty z r/o/znymi wersjami ko/nc/ow linii; zebrano i przet/lumaczono dokumentacj/e 1.00 -- 02.05.97 -- bezp/latne udost/epnienie (BachoTeX '97) 1.03 -- 07.01.98 -- uzupe/lnienie dokumentacji, poprawienie odporno/sci pakietu na egzotyczne dane (CEP.AWK) ========================================================================== S /L O W N I C Z E K ========================================================================== Ghostscript, GS -- wspania/ly interpreter j/ezyka PostScript, stworzony przez Aladdin Enterprise, dost/epny bezp/latnie na zasadach ,,free public license''; aktualna wersja jest cz/esto lepsza i bardziej stabilna od sprzedawanych za tysi/ace dolar/ow interpreter/ow fotona/swietlarek. AWK -- program narz/edziowy, a tak/ze j/ezyk programowania umo/zliwiaj/acy skuteczne i /latwe do zaprogramowania przetwarzania wsadowe plik/ow tekstowych, stworzony w 1977 r. przez Alfreda V. Aho, Petera J. Weinbergera i Briana W. Kernighana. GAWK -- Gnu AWK -- dost/epna bezp/latnie na zasadach ,,GNU Free Software Foundation'' implementacja AWK-a, napisana w 1986 r. przez Paula Rubina oraz Jay Fenlasona z pomoc/a Richarda Stallmana. GNU -- inicjatywa ,,The Free Software Foundation'' niekomercyjnej organizacji zajmuj/acej si/e tworzeniem i rozpowszechnianiem darmowego oprogramowania. Fundacj/e za/lo/zy/l Richard M. Stallman. TeX -- system komputerowego sk/ladu tekstu, stworzony przez Donalda E. Knutha z Uniwersytetu Stanforda, rozpowszechniany jako dobro publiczne. DVIPS -- program tworz/acy pliki PostScript-owe z TeX-owych plik/ow DVI, autorstwa Tomasa Rokickiego z Uniwersytetu Stanforda. DSC -- Document Structuring Convention -- wyznaczony przez firm/e Adobe standard strukturyzacji plik/ow PostScript-owych. ASCII85 -- algorytm kodowania danych binarnych w postaci tekstowej. Koduje ka/zde cztery bajty jako pi/e/c znak/ow z zakresu od ,,%'' do ,,u''; cztery bajty zerowe s/a traktowane inaczej i kodowane jako litera ,,z'' (szczeg/o/ly w dokumentacji j/ezyka PostScript, strony 128--130). RLE -- run length encoding (kodowanie powtarzaj/acych si/e bajt/ow) -- standardowa metoda kompresji danych (szczeg/o/ly w dokumentacji j/ezyka PostScript, strony 133--134). LZW -- algorytm kompresji wymy/slony w 1978 roku przez J. Ziva i A. Lempela, poprawiony przez T. Welcha w 1984 r.; w 1985 roku opatentowany w Stanach Zjednoczonych przez firm/e Unisys, zatrudniaj/ac/a Welcha. Firma Unisys uzna/la, /ze implementacje algorytmu sprzed roku 1985 s/a wolne od op/laty autorskiej. (Informacja zaczerpni/eta z opracowania Nelsona H. F. Beebe, e-mail beebe@math.utah.edu.) DCT -- discrete cosine transform compression (kompresja oparta o numeryczn/a transformat/e kosinusow/a) -- bardzo efektywna, stratna metoda kompresji danych (g/l/ownie graficznych). JPEG -- Joint Photographic Experts Group -- organizacja, kt/ora stworzy/la b/ed/acy standardem format zapisu plik/ow oparty na kompresji algorytmem DCT. Filtr PostScript-owy ,,DCTEncoding'' jest zgodny ze standardem JPEG. GZIP -- program kompresuj/acy stworzony przez GNU Free Software Foundation jako odpowied/x na opatentowanie algorytmu LZW, oparty na bardzo skutecznym i og/olnie dost/epnym algorytmie (wariant algorytmu Lempela i Ziva). Jest on obecnie standardowym narz/edziem kompresji danych w systemach unixowych. Flate -- filtr PostScript-u Level 3 wykorzystuj/acy kompresj/e opart/a o ten sam algorytm, kt/ory u/zywany jest przez program GZIP; nazwa pochodzi od angielskich s/l/ow deflate-inflate. ======================================================================= KONIEC ,,CEPCOP_P.INF''