World: r3wp

If the image is 11mb, the printer would need more memory than that 
to print it, assuming the Postscript has no logic bugs that would 
prevent the printer from rendering the image at all.

I have problem with an image like in this example:

do http://home.tiscali.dk/john.niclasen/postscript/postscript.r
img: to-image layout [box 20x20 red box blue]

write %imagetest.ps postscript [page [translate 100 400 scale 72 
72 image img]]


Try print (or view) the imagetest.ps file. Do you also get an error?

ERROR: /rangecheckESP Ghostscript 815.04: Unrecoverable error, exit 
code 1
 in --string--
Operand stack:
   picstr   70560
Execution stack:

   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval-- 
     2   %stopped_push   --nostringval--   --nostringval--   --nostringval-- 
     false   1   %stopped_push   1   3   %oparray_pop   1   3   %oparray_pop 
     1   3   %oparray_pop   1   3   %oparray_pop   .runexec2   --nostringval-- 
     --nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:

   --dict:1125/1686(ro)(G)--   --dict:0/20(G)--   --dict:108/200(L)--
Current allocation mode is local

That's what I get

Geomol, I wonder if GS can output it's stacks for debugging purposes. 
would that be useful to you?

Since postscript is a printer language, it can print the stacks if 
it encounters an error.

then I suppose it's enough to use the ghostscript console

sure if you're using ghostscript .. I meant if you were testing on 
a postscript printer.

I think it's easier to debug it in ghostscript. The printers I've 
tried this on will not print stack information. Perhaps only if I 
dive really deep into the capabilities of the printer, which I have 
no time for.

You have to write a postscript function that prints the stacks.

Any postscript printer should be able to do that.S

I see, so it's not built-on.

No.  Just a debugging function that you add to your postscript file 
that you are trying to print.

http://www.acumentraining.com/AcumenJournal.html#200504

perhaps that would be a good thing to include in the dialect.

Henrik, I'll look closer at this. Stack output probably won't help 
me much, but thanks for the offer.

this is another PDF about using postscript images http://www.acumentraining.com/AcumenJournal.html#200504

It seems like, I got image to work. Try this:

do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

write %palms.ps postscript [DeviceRGB page [translate 100x400 scale 
72x72 image http://www.rebol.com/view/palms.jpg]]


The file palms.ps can now be viewed or printed. If anyone got problem 
with this, please let me know.

wow, that took a long time to generate.

but it works

! Great! :)

15 seconds at 100% CPU

when adding DeviceRGB in your previous example, that example works 
too.

Maybe because it had to load image from web also!? Try with a local 
version of the image.

and that took less than 1 second to generate.

cool

well, it would be bad if it ate that much CPU, just waiting for network 
stuff.

I load the image with
load-image/update
to be sure to always get latest version.

Maybe your system had a hickup? Try again!

tried several times, same result.

ok

will test with a local file soon

Try take a local copy of postscript.r and change the load-image to 
not do a /update.

writing palms.jpg locally took 1 second

testing postscript generation

perhaps 12 seconds with a local palms.jpg file

what do you do to translate the data? is it in mezzanine form?

Images are implemented in postscript.r using ASCIIHexDecode filter, 
which double the size of image data. It would be better to implement 
ASCII85, which does a 4:5 increase only.


Also images are handled in something called dictionaries in PostScript. 
This require PostScript v. 2.0.

If you look in postscript.r, I encode the image data in line 211-220. 
It's just normal hex written as ASCII, so you get '0'-'9' + 'A'-'F'.

when building the image data, how do you do that? or does ASCIIHexDecode 
do that?

ok

So this is very simple encoding. ASCII85 encoding is a bit more difficult, 
but will take up less space.

perhaps it's equal in speed, I don't know. odd though, I can't see 
what's so slow about that code, other than the newline insertion 
thing

perhaps inserting in images is very slow?

does it need to be done?

It seems to work without the newlines, but then the ps file become 
difficult to enter with e.g. vim. That part is fast, I think. It 
only put in a newline for every 80 chars.

My guess is, that it's the load-image/update that give you performance 
hit. Try change it!

it does not, I tried a local file. 12 seconds.

will try to add some profiling hints

nope, it's the inserting part. the rest is taking no time at all.