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

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.

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).

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?

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.).

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