World: r3wp

That will work with vector images, but not necessarily pictures - 
EPS would have the same problems as Postscript.

AFAIK, EPS is PS without page handling information

Yes. I use things like imagemagick to do the conversion for me from 
binary image ( whatever format ) to eps.

But if the image is big, it remains big ... not that it's a problem 
because it's being dumped to a printer.

it's a problem for speed, but perhaps there really is no way around 
it

exactly because postscript can not handle gif, tiff, png, jpeg etc.

but I was wondering if it accepts some kind of 2 or 4 bit format 
for smaller data sizes. the images I need to use are usually of low 
color.

whereas LaTeX can use jpeg.

well, LaTeX is converted to postscript, so maybe the end result is 
the same.

Here's an article on coverting a jpeg to image using postscript functions 
http://www.tinaja.com/glib/jpg2pdf.pdf

This with large printfiles, it's the same, that happens, if you print 
text using a font, that the printer doesn't know. Everything is converted 
to image data, and one page can be several MB.

The image problem seems to be related to size. I tried to make a 
little image entirely in REBOL, and I can see that. Making a larger 
image, and Preview under OSX can't convert it to PDF. I would like 
to know, if my example above with palms.jpg can be printed on paper.

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.