World: r3wp

Maybe you mean gradient fills?

Need those too.

and matrix

line-pattern

And Gouraud shaded triangle (if anyone uses those).

Hmm still some work to do.

this produces the same output ( pdf anyway ) as John's script

http://www.compkarori.com/reb/ps.r

I was just having a play as well with the postscript dialect.

this is the source file which looks a little different

test: form ps [
	font Times-Roman 40
	linewidth 0
	at 72x720 "REBOL PostScript Dialect"
	at 72x716 line 520x716	
	font Times-Roman 16

 at 96x680 "With this dialect it's possible to easily produce PostScript 
 output."
	font Courier 24
	at 96x600 "You can use different fonts."
	font Times-Roman 16
	gsave
	at 120x550 rotate -30 
	"Make"
	grestore
	gsave
	at 160x450 rotate 30 scale 2 4 "transformations"
	grestore
	at 96x400 "And do graphics:"
	at 100x320 box 200x40 stroke
	gsave
	at 180x240 rotate 20 
	setgray .6 
	box 100x80 fill
	grestore
	at 150x250 line 200x290 180x305 194x340
	font Helvetica-Oblique 12
	at 72x72 "Postscript is copyright Adobe."
]

Good work! And a very fine alternative. This is the time to deside, 
how the dialect should be formed. Situation is, I had no experience 
with PostScript before starting this dialect, so I have no feeling 
about, how the dialect should look. If only there were an SGML definition 
for PostScript, but the closest we come to some rules is the DSC 
(Document Structure Conventions).

Me too!

But I think we should strive to remove all brackets [ .. ] from the 
dialect.

Maybe we can take a look at some examples of real PS output from 
different apps?

Do we need to do that?

As long as we can satisfy out aims of text on paper, and some graphics 
...

The idea with the brackets come from the term "path" in PS. I had 
the feeling, that paths could hold lots of content. Maybe looking 
at other PS output can tell us something about that?

Ahh..

If we end up with lots of paths in our PS files, other might say, 
we produce bloath PS.

my output file is a little shorter than yours, but only because I 
didn't bother creating the prolog / epilog

I think to create those should be a refinement.

because you might only want to create a short postscript fragment 
rather than a script.

yes

We need information about, what can be inside one path, and how they 
are used in other PS files.

In my lates PS output, there is also a problem, where the box and 
the filled box is made. The box ends with a closepath and a stroke, 
but there is no newpath to start the next. I think, that's not 100% 
correct, but it seems to work.

I didn't even use 'newpath !  :(

Ok, definitely need to find out when a newpath command is needed.

presumably, stroke, fill, and show close the existing path.

I read somewhere, that some PS operators force newpath, but it's 
bad practice to leave them out.

maybe just make 'newpath a part of the dialect as well.

That is a problem, because we then leave it up to the user to make 
sure, the rules of PS holds. That's the same as writing PS directly, 
so not much is won.

A good dialect is one with some simple rules, and where it's difficult 
to produce something wrong.

We just need to know a little more, then we can make it almost perfect.

:)

I'm too tired now and am going to bed. Good night!

night

but it makes it easier to program :)

is it me or does translate not work?

I never got as far as implementing translate.  But John's has it.

it's john's version I'm trying it in

mine works .. I'll upload it.

test3: form ps/header [
	gsave
	translate 72x72
	at 0x0 box 72x72 stroke
	grestore
	showpage
]

draws a box at 72x72 where origin is translated to 72x72

test3: form ps/header [
	gsave
	translate 72x72
	newpath
	at 0x0 box 72x72 stroke
	grestore
	showpage
]

{%!
%%Creator: ps.r ver 0.0.4
gsave
72 72 translate
newpath
0 0 moveto 72 0 rlineto 0 72 rlineto -72 0 rlineto closepath
stroke
grestore
showpage

%%EOF

ah, the good old copy trap. for the zillionth time I fell in.

wait for R3 then!

this has to be working by april 22nd. so that's no go.

watcha doing?