World: r3wp

why negative. It is because you read is as a negative. My reaction 
translates to - if PS is good thing to have, then let's have it, 
but then it would be good to have native rebol ps viewer (in AGG) 
or there will be a trouble, if such a thing is dependant upon external 
viewer. And that is my experience here and I can guarantee you, that 
in terms of our big corp it would be a problem. But enough, do what 
you think is best ...

This might be of interest to Robert and Jaime who have new babies 
!

If I get time, I'll see if I can create a web service that turns 
growth data into CDC chart.

Both PostScript and PDF ref. manuals are found on www.adobe.com. 
I took a quick look and found out, that PDF is mainly a document 
format incl. things as hypertext links and logical structure information 
for document interchange. Postscript's primary application is to 
describe the appearance of text, graphical shapes, and sampled images 
on printed and displayed pages. It makes good sense producing PostScript 
from REBOL to enhance printing abilities, and if it's much easier 
than pdf (as Graham points out), there is good probability of success. 
And supporting PostScript doesn't exclude pdf. We can have both, 
and it's two different things with different goals.

Thank you.

One of the main reasons I suggested it is the high likelihood of 
success as you pointed out.

(as a world master here) First, Pekr, I can see how Graham interpreted 
some of your comments as negative ("Graham - either give me native 
rebol post script viewer, or forget it. I will not install ghost 
script..."), and I don't think he's being arrogant. I understand 
your point about wanting people to spend effort on things that are 
valuable to REBOL, but what's valueable to each of us is *completely* 
different in many cases. 


I hope you two can stay on good terms, because you're both valuable 
to the community.

(as a regular REBOLer) I've thought about doing the PS thing, because 
I hoped it would help printing support (and OSX uses DisplayPS, right? 
NeXT did too.). I also thought it would be a cool example, because 
of REBOL's Forth heritage that is very PS like (though I think someone 
once said that PS was *not* based on Forth..whatever). 


It shouldn't be too tough--I even have a couple PS book on my shelf 
if people need something looked up--but, like Pekr, I doubt the general 
practical usefulness for the average REBOL app user without a "full 
stack" of PS tools. That doesn't matter if you want it for yourself 
though, or we can bundle things into a distro for those who want 
it.

Gregg, OSX moved from PS renderer of NeXT to a PDF one. This was 
to save money from licensing the PS engine from Adobe. Currently 
PS is converted to PDF by third party tools. PDF on the other hand 
is direct.

Ahh, thanks for the info.

I thought about this subject yesterday night and yeah, it would be 
nice to be able to do "anything and everything" in Rebol and PS does 
offer that. Besides the kind of charts that Graham showed, things 
like wrapping/flowing text around graphic images would be useful. 
Of course at some point I would most likely convert it to pdf through 
Distiller. 

I totally agree that good clean output is essential. My last programming 
foray in PS was some 16 years ago. At that time it was the only way 
to go for me. I suppose that alone shows the staying power of PS.

Gregg, it's like cgi... unless you've got a web server, cgi is a 
waste of time for you.  If I have a web service that uses a postscript 
dialect to create a postscript image, and then uses ghostscript to 
convert to pdf .. well, that is useful to those running web services, 
but a waste of time for those who don't.

That's why we call them domain specific languages .. they're not 
for everyone, right!

Yup.

pekr, reading your comments seem to focus on a PS viewer. This is 
completely uninteresting to me. I want tools that are native to REBOL 
to allow me to print graphics directly to a printer with the fewest 
amount of 3rd party tools. How many shrinkwrapped apps out there 
need third party tools for something as basic as printing?

I've got a colour laser printer on my network which I think supports 
postscript.  I presume to print a postscript file, I just send it 
to the ip address of the printer?

hum  good question.  I'd like to know this as well... anyone?

I have a jetdirect usb print server at 192.168.1.253

>> port: open/direct tcp://192.168.1.253:9100
>> insert port read %boys-0-36-length-weight.ps
>> close port

and I printed out my postscript file with no problems.

jetdirect print servers use 9100 for data, and 80 for the embedded 
webserver.

That was pretty easy ... create the postscript  file, and send it 
directly to the printer, or print server.

precisely

I wonder if we should use an existing dialect and modify it to product 
ps .. or create one from scratch.

Should we use pair! or not ?

moveto 72x72, or moveto 72 72 
postscript is RPN, so that looks like 72 72 moveto

what about starting from the DRAW dialect?

I guess if the main aim is to take drawings to postscript, then that 
makes sense.

the fastest route definitely. a PS -> DRAW thing would be a nice 
thing to have but DRAW -> PS is the most important right now

So, for example, if we used to plot dialect to draw a graph, we can 
then emit postscript and send directly to the printer.

used the Plot dialect ..

yes, I think it should work like the DRAW function, but instead of 
producing an image it produces a string! value to be used however 
you want it

String! is good.

Or, perhap a block! for further processing?

Say you wanted to insert an eps file into your output.

not sure about the mechanism yet, but maybe yes

An eps file is just a postscript file which is written in a special 
way ...

there is no paper information AFAIK

In the name of science, I repeated the above test and it printed 
out again.

I also tried it with a pdf, as the printer supports direct pdf printing, 
but nothing happened.

interesting. tried different pdfs?

Not yet.

DRAW -> PS is one possibility. Should we on a longer term also have 
a dialect or set of functions, than can produce PS?

that

DRAW is also a function used like:
img: make image! 100x100
DRAW img <some draw commands>

With PostScript, I'm thinking something like:
ps-output: ""
POSTSCRIPT ps-output <some PS commands>


ps-output could then also be a file! or port! and send the output 
directly to the destination.

<some PS commands> in the above is a block of commands with arguments.

Is the aim to take a draw block and process it so that postscript 
is produced.

That's what I understood from Henrik's posts.

It's one way of doing it, and maybe not so bad. I don't know enough 
about PS to see, if DRAW is too limited. Maybe PS has a lot other 
stuff, you wanna do, that is difficult to do in DRAW.

as far as I recall, it has quite a limited command set.

of course, you can define new functions within ps.