World: r3wp

New version of postscript.r uploaded! I've add the prolog %! and 
epilog %%EOF as Graham suggested. I also wrapped paths in the postscripts 
commands gsave and grestore, so transformations give less trouble. 
Try this:

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

write %test.ps postscript load http://home.tiscali.dk/john.niclasen/postscript/test.txt


You now have a postscript file "test.ps" produced by the dialect. 
It's content looks like this:
http://home.tiscali.dk/john.niclasen/postscript/test.png

To see, how using the dialect look in use, see the "test.txt" file.

I'm building EAN13 barcode support for PS now. not very hard

The output postscript file from the dialect can be sent to a postscript 
printer, so no driver is needed.

Great, Henrik!

The dialect is just a version 0.2.3, so it can be better!

now I'm imagining: this is really lowlevel stuff, but I think it 
would be neat to build standardized higher level primitives. a barcode 
is such a primitive. barcharts, 3D views and complex symbols could 
be other types of primitives. just brainstorming...

Yes, good ideas! It's not the meaning, that people should write in 
the postscript dialect directly. Building higher level dialects and 
primitives/applications on top of the dialect is the way to go.

but it should also be consistent. a dialect with primitives? a library?

The postscript dialect is just there to make printing easier, as 
was your intension with making this group.

that's true... maybe it would be better to approach it through DRAW 
and let postscript.r do the dirty work

Developer libraries and standards are good! It's been a big part 
of my job the last 15 years or so making programming libraries for 
developers. If I could make money developing REBOL standards and 
programming libraries, I would use more time on it.

I'm sometimes thinking about, if REBOL developers are willing to 
invest in programming libraries. Maybe there are too few?

I think there are too few, then again, more might come if there was 
a consistent set of libraries. more than the current collection of 
scripts on rebol.org anyway

I think this was the idea of the Rebol Powerpack?

and slim.

and steel.

geomol, I don't know if you've seen this link: http://www.cs.wisc.edu/~ghost/doc/gripes.htm

No, didn't know that one. Good to stick to the rules, thanks!

Let's see ... what is needed more in the dialect, before a DRAW -> 
PostScript converter can be made? Images! Something else?

curves?

fills?

haha, you're faster than me. I was just going to say curves.

How fills? You can fill a box with boxfill.

We also miss circle.

and clipping ... argh, tough one, me thinks.

arcs

is there any typography handling?

Not in DRAW, I think.

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.