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''