World: r3wp

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.

You say, you tried a local file, but did you change the load-image 
in postscript.r?

so I think there should be an option to leave that out, or by default 
not have it. I'm guessing most people want to generate and print 
PS file, rather than read and edit them by hand.

ok, the inserting of the newlines is the problem?

didn't try that with /update yet. will have to be sure

yep, same thing without /update.

If the inserting is the problem, then I might be able to fix that 
with copy to another series in stead. Problem with insert is, when 
you have large series, it has to move the content down the memory.

I'm trying to remove that code right now to see if it improves performance.

now GS won't read the PS file, but the generation is much much faster. 
less than 0.5 secs

Just uncomment after the trim in line 213.

did that