World: r3wp

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?

of lines

I've seen a problem with a barcode reader that could not read codes 
printed from one expensive printer and it would read them fine if 
printed from another cheap printer

line thickness can be specified in both ps and view.

turned out the expensive printer was able to separate two parallel 
lines just by a hair's width, where they should appear as a single 
line at double width of one line. that made the barcodes unreadable.

that was bad programming.

it relied a printer deficiency to work.

I didn't discover the error until I tried it on the expensive printer. 
besides the size and position of the line was supposed to be correct. 
the barcode was created with PDF Maker

and it looks correct when viewed in a PDF Viewer

even when you drill down on the bars to high resolution?  Remember 
screen res is only 72 dpi .. lower than your cheap printer.

PS has setlinewidth, and setting it to 0 will make is as thin, as 
the device can do.

John, before we go further in developing this, I would like to know 
what license is going to be applied.  I note that yu have copyright 
nicomsoft in the header.