World: r3wp

this ..  .75 setgray uses a gray colour for the text.

The dialect can't cope with that yet.

This is a good start though.

So far, you can specify font, set position and print text.

so, you need also the %! at the beginning, and a showpage at the 
end.

things like 'box can be defined as a function in postscript.

Desitions have to be made about the dialect structure. Should the 
outer block consist of font-specifications and pages, or isn't that 
structure the best for PS? A better understanding of PS is needed 
to answer.

so, you would probably need some predefined functions that are also 
emitted.

Is the main aim to do text, or translate draw images?

I would aim for an implementation of PS functionality as a REBOL 
dialect. Nothing to do with draw yet.

we have Gabriele's pdf dialect to use a model.

his dialect must cover the same problems .. as pdf is a subset of 
postscript.

at 72x72 font Helvetica-Bold 6.0 "Hello World!"

I'll look at all the PS operators to get a view of the whole thing. 
Then define a structure for the dialect (probably top-concept of 
a page), and then implement the operators most needed.

this looks easier to write.

Would it be normal in PS to define the font before anything else, 
and then describe pages with paths? Is that the structure?

I wonder if we can't just use Gabriele's dialect and build a different 
emitter.

I'm not sure .. I've only read about postscript in the last day.

It'll take time for me to read others dialect rules. It'll probably 
be faster for me to make the dialect, so I know, what's going on 
everywhere.

New version. The postscript block consists of font definitions and 
pages. A page consists of paths and transformations. Try:
do http://home.tiscali.dk/john.niclasen/postscript/postscript.r

print postscript [font [Times-Roman 20] page [path [at 72x72 rotate 
45 "Hello World!"]]]

The "page" and "path" words are optional, so this'll give same result:

print postscript [font [Times-Roman 20] [[at 72x72 rotate 45 "Hello 
World!"]]]

A postscript block can have several pages, and every page can have 
several paths.

I found this document describing PostScript structure:

http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf

PostScript has a lot of operators (commands). For this REBOL dialect 
to be usefull, we should keep the number of features at a minimum. 
It's always hard to learn something new, and if the number of commands 
is too big, less will use it. I would like feedback on, what features 
should be supported in the dialect for a first version. This dialect 
can then be used in REBOL programs, that would like to do PostScript 
output. And I could make a PostScript output from my NicomDoc format. 
And then we could also have a DRAW -> PS converter.

I don't want to interrupt your concrete talk here, but I think I 
was a bit misunderstood. By "or forget it" I did not mean forget 
bringing PS to rebol, but "it" was pointing to ghostviewer. I am 
the last, who would not want to do everything in Rebol. So Henrik 
actually contradicts himself a bit stating that he wants to limit 
number of external apps = bring PS to rebol, but then how to do a 
preview?

PS -> VIEW maybe?

In fact - my question could be just simplified - how do we do print 
preview without GhostView or other PS viewer tools? If that is "somehow" 
possible, then it is only good. That is why I referred to the need 
of AGG based preview, to actually save third app usage - a PS viewer.

sorry, PS -> DRAW

OK, enough, and now something at least a bit more constructive:

I think, what Henrik is thinking about is, that if he already has 
something on his screen produced in REBOL, e.g. something from DRAW, 
then he just want to print it easily. But you're right, if we get 
all different PS-files in REBOL, how do we preview them then? I don't 
want to, I want to easily print a NicomDoc document, I alread see 
on my monitor.

... more generally in rcentral.org

One thing that may become an issue on the future is syncronization 
of Color Profiles. Different display and printing devices hace different 
gamma curves. This should be an issue for black and withe and vector 
graffics, put if you are printing a rebol screen. Then you may need 
to take the color profiles into consideration.

geomol understood me correctly :-)

even just by making vectorgraphics and text in PS now is great. it'll 
almost fulfill my needs

Yes. Henrik go for it. After all you code what you need.

and we'll use it  ;-)

However, my point is that for printing PS is not the universal solution, 
but having a partial  solution is better than having none.

well we can convert a draw block to-image and then send that out 
directly.. but its very slow to print... I mean sending 300 dpi or 
more bitmaps to a printer is tedious.

maxim, I don't think it's reliable anyway if exact sizes are needed, 
for example for filling out pre-printed forms

300dpi = 300 ticks in an inch.  if you know the printer edges to 
be 1/2 inch, then you can juste calculate a 2250 wide bitmap (using 
US letter size paper)  and send it .  this works.  simple math .

I used to do it on amiga...

If I knew how PCL wraps images I'd do it on PC too... I've just not 
needed to do printing with rebol, for which html didn't solve my 
needs... yet...

one of the reasons also for a DRAW block is that you can preview 
your output first. Not so easy with PDF Maker...

not saying its not needed.

and you can scale it to whatever resolution...

a good solution might be to use decimal 0-1 values and just recompute 
them to whatever output you are using (so adapt to any paper/bitmap 
size)

geomol, on feedback, I'm not entirely sure what the initial supported 
functions could be since I'm not an expert on DRAW, but at least 
support for text and vector graphics. the coordinate system for DRAW 
and PS would be nice if it could work identically.

DRAW uses pixels... I am pretty sure PS does not.

right, but that should be translatable? DRAW can scale graphics up 
or down.

to simulate DPI density