World: r3wp

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

yes.

AGG DRAW is pure vector gfx

Ok, text and vector graphics ... and some grey-tone/colour for a 
start. And then the rotate, scale and translate, that's already included 
in my postscript dialect.

what about page handling, page sizes, page breaks, etc?

the view preview does not have to be perfect .. it just has to be 
good enough.

positioning and size is the most important in the preview. rendering 
and prettiness is less important

for line elements, and text, that should not be a problem ( given 
the same fonts ).

All the more exotic drawing commands may be though.

Like you, I'm primarily interested in text, and lines ( my application 
uses LaTeX at present to do text ).

I need to output tables and text at specific locations as well as 
bar codes

straight lines, boxes

that should be very easy to do with a postscript dialect.

managing line thickness is going to be important, but that may not 
be so hard

thickness?

of lines, or text, or what?