Názory k článku
Grafický metaformát PostScript

Vyborny clanek a vyborny serial. Jen mala drobnost - neznamena E v EPS spise encapsulated??? (Vetsinou jsem na to na v tomto tvaru)
S uctou Luinar

take si myslim

Ano, mate pravdu. Omlouvam se, uz jsem z tech embedded zarizeni, do kterych semtam vrtam, uplne zmatenej.

Díky za kvalitní čtivo, těším se na další díly.

procesor v tiskarne je obvykle pomaly a ma malo pameti ve srovnani s prumernym PC, pri tisku delsiho dokumentu je rozdil v rychlosti celkem poznat - sw RIP v PC je vyrazne rychlejsi

a slozity dokument treba nejde vytisknout vubec, protoze dojde pamet v tiskarne

GDI a PCL tiskarny bezne pouzivaji pri prenosu kompresi bitmap, na rozdil od PS vystupu z normalnich DTP programu

Záleží na tom, co se porovnává. Taková HP LS-4 se samozřejmě vedle moderního PCčka nemůže co do rychlosti srovnávat, ale v době svého zavedení na trh mi připadla rychlejší, než SW RIPy.

V práci jsem měl PostScriptovou tiskárnu, která opravdu stránky chrlila neuvěřitelně rychle , nebyl poznat žádný výrazný rozdíl mezi první stránkou a stránkami dalšími (akorát se ty vytištěné špatně vyndávaly ze zásobníku, nesmělo se zavadit o tu, co právě vylézala, protože měla moc citlivé senzory na posun papíru :-) Pravda je, že ten PostScript, co jsem tiskl, byl poměrně jednoduchý - výstup z TeXu + jednoduchá vektorová grafika.

Osvitovky asi nemá cenu porovnávat, viděl jsem pouze PostScriptové a některé modernější zvládnou dokonce i PDF. Ty však problémy s pamětí většinou netrpí (někdy je k dispozici i HDD).

Zajimalo by me, jestli jsou nejake figle, jak ohlidat, aby nekdo na postscriptovou tiskarnu (nebo PS tiskovy server) neposlal treba tu Game of life (obsahuje nekonecny cyklus), a tim to nezahltil. Na prvni pohled me pripada, ze u ciste-datoveho formatu obvykloe neklonecny cyklus nehrozi, a proti obyc zahlceni udelat treba quoty/omezeni/zpoplatneni na pocet stranek.
Jestli nekdo vite, tak dik za odpoved.

Obavam se, ze obecne to nepujde. PostScript je Turingovsky kompletni jazyk a tam pouhou analyzou zdrojaku nekonecny cyklus obecne nezjistite (halting problem?). Mozna maji nektere tiskarny hlidac timeoutu, ale osobne bych ten problem hodil spis na uzivatele - aneb logovat vsechno, co jde na tiskarnu (ne nutne obsah, pouze jmeno tiskove ulohy, IP odesilatele, cas tisku, pocet stran atd.)

Jiste, u ciste datoveho formatu (PCL) tohle nehrozi, ale stejne v nem nelze ohlidat vsechno - napriklad spatny PCL muze zapricinit tisk treba 1000 stran a na kazde bude pouze jedno obrovske pismeno (obvykly problem pri nedostatku pameti v tiskarne).

Jednoduse. Zapnout accounting a vybirat penize za kazdou CPU-minutu RIPu, prip. kazdou minutu po prekroceni denni / tydenni / mesicni kvoty.

Jinymi slovy, administrativnimi prostredky mimo IT system.

Programy, které PostScript generují z jiného formátu se o čitelnost nestarají záměrně. Svádělo by to k provádění dalších úprav na výstupu generátoru místo na vstupu, což je silně nežádoucí.

No, ale to muze uzivatelum hodne zneprijemnit zivot. Dam priklad: sestavovali jsme sbornik pro jednu dost vyznamnou mezinarodni konferenci a prispevky samozrejme (podle CFP) prisly v PostScriptu.

S tim by nebyl zadny problem, ovsem my jsme museli ty stranky dat za sebe, separovat barevne obrazky (ty se tiskly na jine tiskarne na kridovy papir) a cele to opatrit nahore hlavickou s nazvem clanku/jmenem autora a dole cislem stranky. S rozumne generovanymi PostScriptovymi soubory se dalo delat docela dobre, proste se nova slova (funkce, makra) pro vytisteni nazvu clanku a ocislovani daly na spravne misto pred a za prikaz SHOWPAGE. Ale vyznat se v nekterych vystupech treba z Wordu bylo na povazenou, tam musela nastoupit rucni editace misto pomerne jednoducheho skriptu.

Tim obfuscated kodem se stejne nic neskryje, pouze to prida praci pri dekodovani.

ad první odstavec: to máte pravdu, v tomto případě je to jednoznačně "humus" a nechápu, proč se vydavatel nedohodl s autorem na nové projetí TeXem po přidání těch šesti stran. Vždyť toto je otázka pár minut, ruční práce s PostScriptem zabere mnohem delší čas.

Ten sborník se asi jiným způsobem elektronicky upravit nedal a ruční dopsání hlavičky a patičky do PostScriptu bylo docela poučné. S těmi nároky na autory textů se nedalo nic dělat - CFP vypsala mezinárodní komise a byl tam snad zadán i stylový soubor pro LaTeX a Word a jako výstup (camera ready) PostScript.

S CM fonty jsem to trošku zjednodušil. TeX pracuje pouze s metrikami, tomu je jedno, jak jsou fonty zadány, potřebuje znát pouze rozměry jednotlivých znaků + pár dalších informací (kerning...). V DVI jsou uvedeny pouze odkazy na jednotlivé znaky, ostatně proto jsou ty soubory tak kompaktní. Při zpracování DVI->PS se buď vezmou rastrované CM fonty vzniklé METAFONTem (PK či GF) nebo se také mohou použít PostScriptové CM fonty (PFA/PFB), to už však vyžaduje hrátky s vektorovými fonty apod. Ale "dvipdfm" tyto PostScriptové CM fonty využije celkem bez problémů, stejně jako pdfTeX.

Osobně mám lepší zkušenosti s rastrovanými CM fonty. Zaprve je jednodušší takový soubor vytvořit pomocí dvips a zadruhé je opravdu přesně vidět, co tiskárna/osvitka vlastně vytiskne. S outline fonty bývají problémy, tam se na nějaký pixel doprava či doleva nehledí, taky osvit trvá delší dobu. Samozřejmě, že takový PostScript vypadá při prohlížení na obrazovce hrozně (stejně jako po převodu do PDF), protože přerastrovávat bitmapy je vždycky problematické.

Mám jednu zkušenost s tiskem PostScriptového souboru (výstup z dvips) na PostScriptové tiskárně. Dotyčný mi můj PostScriptový dokument začal tisknout přes GhosScript (se SW zpracováním PostScriptu). Počítač byl spojený s tiskárnou přes LPT. Tisk šel pochopitelně velmi pomalu díky přenosu po LPT.

Po tom, co jsem toho člověka přesvědčil, že dělá chybu a měl by to posílat jako čistý PostScript přímo do tiskárny, se tisk pochopitelně velmi zrychlil. Než se mi ho ale povedlo k tomuto kroku přesvědčit, tak se vytisklo pár stránek, na kterých byly v originální podobě jpg obrázky. Co mě velmi zarazilo, byl velký rozdíl v kvalitě rasterizace těchto obrázků SW GhostScriptem a RIPem (HW PostScriptem přímo v tiskárně). GhostScriptová rasterizace byla velmi nekvalitní a projevovalo se to hlavně viditelnými mapami u jemných přechodů barev. Na obrázku vznikala velmi odpudivá mozaika (představte si velmi vysokou kompresi do jpg). Tisk přímo v PostCriptu byl velmi kvalitní včetně jemných přechodů barev.

Čím to mohlo být způsobeno? Je opravdu GhostScript tak špatný v rasterizaci?

Řekl bych že tiskárna má optimalizovanou rasterizaci s ohledem na své schopnosti, dpi, lpi, typ rastru apod. Takže je vhodnější jí předložit obrázek v nižším dpi ať si jej převzorkuje sama, než ve vysokém dpi aby bádala, zda upřednostnit jemnost kresby nebo škálu odstínů.

Podobne problemy jsem taky s Ghostscriptem mel. IMHO to muze byt zpusobeno nekolikerym prerastrovanim tech obrazku. Ghostscript si totiz precte, ze vystup posila na tiskarnu s dejme tomu 600DPI a obrazek ma samozrejme jine DPI (treba 72). Tak provede prerastrovani, coz uz z principu nedopada dobre. Idealni je nechat delat tyto low-level veci primo tiskarnou, pouze sami tvurci tiskarny znaji vsechny jeji interni moznosti (otaceni barvoveho rastru apod.).

Mam takovy problem, delam sablonky na Ronju a pro kazdou sirku trubky je potreba jina sablonka, a sirek trubek je tolik co prumeru cocek, cili dost nespocetne :)

Slo by napsat program v postscriptu co by ty sablonky generoval kdyby byla sablonka naprogramovana v nejakym jazyce co by operoval s body, primkaci, pruseciky, kruznicemi apod.?

Jak se treba udela carkovana cara a nastavi tloustka? Umi to taky sinus kosinus ctyri piva deskriptiva?

Neco jako CAD, ale parametrickej. Qcad je v tomhle ohledu celkem nahovno.

Já bych na to buď vytvořil prográmek v nějakém Vašem oblíbeném programovacím jazyce (C, Perl, Python, Basic :-), který svůj výstup zformátuje do PostScriptu, nebo - pokud to má opravdu být parametrické - bych zkusil METAPOST. Přecejen v PostScriptu se dělají výpočty průsečíků stejně složitě, jako v ostatních imperativních jazycích, speciální operátory na řešení rovnic, průsečíků atd. (ala METAFONT či METAPOST) zde nenajdete. Z METAPOSTu vyleze nefalšovaný PostScript, ten je možné buď publikovat (ať si každej plošňák vyleptá sám) nebo přes GS převést do PDF.

Goniometrie v PS:
klasické postfixové funkce sin, cos...:
10 sin

pokud by něco chybělo, dá se přes /def vytvořit nová funkce s libovolným počtem parametrů i návratových hodnot!

Tloušťka čáry (obecně cesty) v PS:

newpath
100 100 moveto
200 200 lineto
2 setlinewidth
stroke