Problemy s dvips...

[Zdenek Wagner]

On Tue, 21 May 2002, Ladislav Bitto wrote:

> ked kvoli tej presnosti (lepsie povedane - na rozliseni nezavisle) som zacal
> sam kodovat priamo do PS -  vsimol som, ze DVIPS mi vytvaral "rychlejsi"
> (teda s GS rychlejsie nacitany) PS subor. Vtedy som si vsimol, ze vlastne
> za kazdy bod dava newpath. Moja prva idea bola - mam krivku s 5000 bodmi -
> napisem na prvy moveto a potom 4999 krat lineto. Mohol som ist na obed, ked
> som sa vratil subor bol na obrazovke.
>
> Nevedel som si vysvetlit, ze preco niektore PS subory ktore dostavam (aj zo
> zahranicia) sa nacitavaju velmi pomaly. Uz viem "vyrobit rychlejsi" PS subor
> prave tym, ze experimentujem  (optimalizujem??) s tym stroke. Neviem ako
> presne GS cita a vynasa subor na obrazovku - podarilo sa mi niekedy
> povodne 1 minutove nacitavanie cvrknut na par sekund (hoci subor tym padom
> je dokonca vacsi - je tam viac krat stroke........).
>
Cela cesta se rastruje najednou v okamziku, kdy se narazi na stroke. Pokud
rozdelite cestu na vice samostatnych casti, pak pro docasne skladovani
jednotlivych elementu staci mensi pamet. Jak se to projevi na rychlosti
nejsem schopen obecne rici. Muze to byt jine v GS, jine na tiskarne, jine
v osvitce, jine v Distilleru. Pri rozdeleni lomene cary na vice
samostatnych segmentu vsak RIP nebude brat v uvahu currentmitterlimit a
dalsi parametry, ktere se pouzivaji pri spojovani. V nekterych pripadech
to muze byt videt. Nektere programy produkuji nesouvisle objekty tak, ze
pouzivaji rmoveto a daji az jeden stroke na konec. To si myslim, ze je
zcela zbytecne plytvani pameti.

> Zdravi
> Ladislav Bitto
>
> > Zdenek Wagner
>
>
>
>
>

Zdenek Wagner
e-mail: wagner at mbox.cesnet.cz  or  wagner at icpf.cas.cz

see also http://www.icpf.cas.cz/wagner/
         http://icebearsoft.euweb.cz