summaryrefslogtreecommitdiff
path: root/support/pstools/cep/cepcop_p.inf
blob: 9e5ab9715a07d8574e4ba37107a9644e96a6f758 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
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''