World: r3wp

and I printed out my postscript file with no problems.

jetdirect print servers use 9100 for data, and 80 for the embedded 
webserver.

That was pretty easy ... create the postscript  file, and send it 
directly to the printer, or print server.

precisely

I wonder if we should use an existing dialect and modify it to product 
ps .. or create one from scratch.

Should we use pair! or not ?

moveto 72x72, or moveto 72 72 
postscript is RPN, so that looks like 72 72 moveto

what about starting from the DRAW dialect?

I guess if the main aim is to take drawings to postscript, then that 
makes sense.

the fastest route definitely. a PS -> DRAW thing would be a nice 
thing to have but DRAW -> PS is the most important right now

So, for example, if we used to plot dialect to draw a graph, we can 
then emit postscript and send directly to the printer.

used the Plot dialect ..

yes, I think it should work like the DRAW function, but instead of 
producing an image it produces a string! value to be used however 
you want it

String! is good.

Or, perhap a block! for further processing?

Say you wanted to insert an eps file into your output.

not sure about the mechanism yet, but maybe yes

An eps file is just a postscript file which is written in a special 
way ...

there is no paper information AFAIK

In the name of science, I repeated the above test and it printed 
out again.

I also tried it with a pdf, as the printer supports direct pdf printing, 
but nothing happened.

interesting. tried different pdfs?

Not yet.

DRAW -> PS is one possibility. Should we on a longer term also have 
a dialect or set of functions, than can produce PS?

that

DRAW is also a function used like:
img: make image! 100x100
DRAW img <some draw commands>

With PostScript, I'm thinking something like:
ps-output: ""
POSTSCRIPT ps-output <some PS commands>


ps-output could then also be a file! or port! and send the output 
directly to the destination.

<some PS commands> in the above is a block of commands with arguments.

Is the aim to take a draw block and process it so that postscript 
is produced.

That's what I understood from Henrik's posts.

It's one way of doing it, and maybe not so bad. I don't know enough 
about PS to see, if DRAW is too limited. Maybe PS has a lot other 
stuff, you wanna do, that is difficult to do in DRAW.

as far as I recall, it has quite a limited command set.

of course, you can define new functions within ps.

The DRAW approach is, that if you can produce your output in a DRAW 
block, then you can also print it using PS. My approach is to make 
a PS dialect, and keep DRAW out of is. With my approach, you can 
print from REBOL/Core too. I guess, we can have both approaches without 
problem.

And both will be usefull for different situations.

but using a draw dialect is possible in core .. u just can't render 
it.

Oh, you're right. :-)

but let's start with a postscript dialect and then see if we can 
retrofit draw to it.

that way we are not constrained by draw.

Then I just need a list of PS commands to get started on the dialect.

since rebol3 is coming, and View may well change, it makes less sense 
to stick to the past.

this has a reference at the end : http://www.cs.indiana.edu/docproject/programming/postscript/postscript.html

Is this works, you can then render your paint images to postscript 
printers :)

Is it the "Index of Operators" in the link, you gave?

yes.

add, arc, ...translate

yes.

pen red
            line 30x30 50x20 70x70 40x50

newpath
	1 0 0 setrgbcolor
	30 30 moveto
	50 20 lineto
	70 70 lineto
	40 50 lineto
	stroke

pen blue
            box 20x20 80x80

newpath
	0 0 1 setrgbcolor
	20 20 moveto
	60 0 rlineto
	0 60 rlineto
	-60 0 rlineto
	closepath stroke