[9fans] gs

[9fans] gs

[Steve Simon]

Anyone get anywhre tracking down the problems with gs? ps2pdf seems
to reliably suicide thusly:

gs_screen_currentpoint(penum=0x652f9c,ppt=0xdfffdd2c)+0x7f /sys/src/cmd/gs/src/gshtscr.c:561
screen_sample(i_ctx_p=0x31bbec)+0x2a /sys/src/cmd/gs/src/zht.c:187
set_screen_continue(i_ctx_p=0x31bbec)+0x5f /sys/src/cmd/gs/src/zht.c:225
interp(pi_ctx_p=0x2e53a4,pref=0xdfffe0a8,perror_object=0xdfffe310)+0x27ad /sys/src/cmd/gs/src/interp.c:1157
...

I can use an old version from my venti I guess but it would be nice to
have a working version again.

Anyone with a knowledge of debugging floating point with acid (I have no ideas)
willing to make a guess as to the problem? This will do it every time.

troff -ms /sys/doc/lp.ms -T post | lp -d stdout | ps2pdf > /dev/null

-Steve

Re: [9fans] gs

[Bruce Ellis]

writing a postscript interpreter that kinda works is not a very
hard task.  writing a ps interpreter that gets the graphics right,
particularly colour, is very tedious and takes a lot of man hours.
optimizing the interpreter so it spits out >20 pages/min is not fun.
i've been involved in the writing of three ps interpreters.
i believe there are still printers in the wild, and even being sold,
that have the undocumented %brucee inbuilt file (my 48x48x1,
a one liner can image it full-page).

brucee

On 10/4/06, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote:
> On Tue Oct  3 16:49:10 EDT 2006, knapjack@gmail.com wrote:
> > ...
> > ...but from the looks of it, maybe it would be easier to "fix"
> > ghostscript by making it faster/slimmer/etc.  I wonder if it runs
> > better on some architectures than others?  If so, sounds like a good
> > job for a cpu server.
> >
> > -Jack
>
> As we get older, faster/slimmer/etc. gets harder and harder
> and eventually we just buy bigger jeans.
>

Re: [9fans] gs

[jmk]

On Tue Oct  3 16:49:10 EDT 2006, knapjack@gmail.com wrote:
> ...
> ...but from the looks of it, maybe it would be easier to "fix"
> ghostscript by making it faster/slimmer/etc.  I wonder if it runs
> better on some architectures than others?  If so, sounds like a good
> job for a cpu server.
> 
> -Jack

As we get older, faster/slimmer/etc. gets harder and harder
and eventually we just buy bigger jeans.

Re: [9fans] gs

[Andy Newman]

LiteStar numnums wrote:
> I should think that the real reason that PostScript is so slow is
> that the graphics rely upon someone who should have really optimised
> some the workings out of their source file...

In a previous life I worked on graphics systems similar in nature
to Postscript (language + graphics lib).  Profiling such things,
including older versions of gs, shows a general pattern of around
50% of the time in an average render (for some value of average)
is spent writing runs of pixels to the output image.  The memory
ops hurt a lot. When accelerating these things (i.e. throwing h/w
at it) typically the first thing you want to do is have the h/w
generate pixel runs from some run-length representation used in
the s/w.  Increased device spatial and color resolutions just make
this more true with the associated increase in memory requirements
for images.  Modern CPU/memory characteristics may have altered
that 50% figure, it's been a while since I measured it, but I don't
see it being vastly different (famous last words :).  The nature
of image rendering, and RIPs, place high demands on memory systems
and it is easy to NOT get good rendering throughput solely due to
memory related issues.  Also the language interpreter itself can
be a bottleneck if not optimized for handling large inputs.  The
programs these interpreters generally process are very large but
relatively simple - few loops, some subroutines but lots and lots
(many millions if not tens of millions) of lexemes to read.

Re: [9fans] gs

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

You can scratch RoPS of that list: anything that it does do, it not only
does it slowly, but improperly. To make matters worse, 'paid' version is no
better.
I had a discussion with Manfred von Thun (you know, the gentleman who
created Joy) about this while I was working on a language that was similar
to postscript & joy. He was interested in the design aspects we were
discussing, but was hesitant about the PS aspects I was using. I should
think that the real reason that PostScript is so slow is that the graphics
rely upon someone who should have really optimised some the workings out of
their source file...
Just my $0.02 (or 0.01 GBP)

On 10/3/06, Jack Johnson <knapjack@gmail.com> wrote:
>
> On 10/3/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > out of idle interest, why has there never been a replacement?
> > is it really that hard?
>
> That's a great question.  I Googled for some leads:
>
> "Saffron includes an all-Java PostScript(r) interpreter"
> http://www.dynalivery.com/customersupport/Saffron_FAQs/SaffronInfo.html
>
> "The RoPS interpreter is a Microsoft Windows implementation of the
> PostScript programming language interpreter"
> http://www.rops.org/
>
> There is some interesting detail stuff here that I'd want to re-read
> if I were going to write an interpreter from scratch:
> http://www.anastigmatix.net/postscript/direct.html
>
> This might also make for a good jumping-off point:
> http://serl.cs.colorado.edu/~arcadia/Software/tps.html
>
> ...but from the looks of it, maybe it would be easier to "fix"
> ghostscript by making it faster/slimmer/etc.  I wonder if it runs
> better on some architectures than others?  If so, sounds like a good
> job for a cpu server.
>
> -Jack
>



-- 
If work and leisure are soon to be subordinated to this one utopian
principle -- absolute busyness -- then utopia and melancholy will come to
coincide: an age without conflict will dawn, perpetually busy -- and without
consciousness.

-- Günter Grass

[-- Attachment #2: Type: text/html, Size: 2706 bytes --]

Re: [9fans] gs

[Jack Johnson]

On 10/3/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> out of idle interest, why has there never been a replacement?
> is it really that hard?

That's a great question.  I Googled for some leads:

"Saffron includes an all-Java PostScript(r) interpreter"
http://www.dynalivery.com/customersupport/Saffron_FAQs/SaffronInfo.html

"The RoPS interpreter is a Microsoft Windows implementation of the
PostScript programming language interpreter"
http://www.rops.org/

There is some interesting detail stuff here that I'd want to re-read
if I were going to write an interpreter from scratch:
http://www.anastigmatix.net/postscript/direct.html

This might also make for a good jumping-off point:
http://serl.cs.colorado.edu/~arcadia/Software/tps.html

...but from the looks of it, maybe it would be easier to "fix"
ghostscript by making it faster/slimmer/etc.  I wonder if it runs
better on some architectures than others?  If so, sounds like a good
job for a cpu server.

-Jack

Re: [9fans] gs

[Francisco J Ballesteros]

I'm curious. any other interpreter that could be ported?

On 10/3/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> as tedious as waiting for gs to do something is waiting
> for db to load all its symbols to debug it not doing something.
> if they ever find another candidate for a planet to replace pluto,
> they should call it `ghostscript'.  it will be big enough to qualify.
>
> out of idle interest, why has there never been a replacement?
> is it really that hard?
>
>
>

Re: [9fans] gs

[geoff]

In first edition, there was a home-grown postscript interpreter, psi,
but it was replaced by gs in second edition.  The degree of difficulty
depends upon what `it' is.  gs can interpret and emit Postscript or
PDF of varying versions, and includes a substantial set of Postscript
fonts.  As I recall, just getting a Postscript interpreter to render
reasonably quickly (er, less than pessimally slowly) is quite a job.
PDF seems to be an attempt to rein in the full generality of the
Postscript language.

Perhaps the people who make Forth interpreters could make a fast
Postscript interpreter, though I suspect that graphics is the
bottleneck.

[9fans] gs

[Charles Forsyth]

as tedious as waiting for gs to do something is waiting
for db to load all its symbols to debug it not doing something.
if they ever find another candidate for a planet to replace pluto,
they should call it `ghostscript'.  it will be big enough to qualify.

out of idle interest, why has there never been a replacement?
is it really that hard?