World: r3wp

Henrik, yes we can add some 'options' for clockwise/anticlockwise 
etc. but keep in mind every such decission at runtime steals performance 
so sometime is better to generate the DRAW dialect with properly 
converted values.

(It is really so hard to invert the rotation values at Rebol level 
when you need it?)

negate angle ;looks easy

r: rot: 0 view layout [origin 0 box 400x400 white effect [draw [pen 
black translate 200x200 rotate

 rot translate -200x-200 box 100x150 300x250]] rate 0 feel [engage: 
 func [f a e][if a = 'time [r: r +
 1 rot: 360 // 360 - r show f]]]]

(just paste to console)

I like the look of DRAW! :-) (Of course it's due to AGG.) I still 
miss a version of REBOL for Mac with full DRAW, as the Windows version 
has it.

does'n't it have full draw, except fonts?

btw - what happened to your Reluxe Paint? No other ambitions with 
that project?

Pekr, yes I still have Canvas RPaint on hold until I can release 
a final version 1.0 for Windows, OS X and Linux at the same time. 
Some DRAW things are missing, which Windows version has.

do you need cross-platform compatibility for intitial release? Hmm, 
maybe so, as a marketing advantage ...

When I was just about to release it, I desided to wait for better 
support of DRAW on the other platforms (and in some way for rebcode 
too). Looking back, I should maybe have release it almost a year 
ago. It's just, that Windows always get the good stuff. I use OS 
X now, and REBOL is cross-platform, so a thing like RPaint should 
be the same on all platforms. I'm also concerned about marketing, 
as you say. Releasing for three platforms at the same time is preferable 
for me.

understandable ....

... but then it might also mean to wait for year or more, because 
I don't believe 2.6 kernel SDK gets fixed to the state, where OS-X 
and Linux versions get some Windows present features. I think that 
RT will concentrate upon portability of R3, and hence you will probably 
have to wait for View based upon R3 - of course, that is just my 
guess ....

We don't know for sure. That Carl is using OS X daily now might be 
a good thing for my situation. We can hope, wait and see.

I showed this REBOL postscript thing to some work colleagues, and 
they asked about support for tray selection on the printer (you typically 
have different paper in each tray). Does anyone know, if it's possible 
to choose tray from postscript?

Another thing is paper type selection. With this you tell what paper 
type, you need, and the printer know, what type of paper is in each 
tray (it's possible to specify that on the printer). Paper type selection 
has some benefit over tray selection.

I didn't figure it out so I had to use the tray selector in the windows 
printer driver to do this.

REBOL PostScript dialect v. 0.3.1 released: http://home.tiscali.dk/john.niclasen/postscript/postscript.r

Documentation here: http://home.tiscali.dk/john.niclasen/postscript/postscript.html

Added possibility to specify some sizes as both pair! or two number!. 
Added alternative spelling of setcolour.

Do this in a REBOL prompt to run the test:

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

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

Now the file %test.ps holds the postscript output.

use the PSC to set trays

It seems, the PostScript operator 'setpagedevice' can be used to 
set MediaType to e.g. 'Plain', 'Letterhead' or 'Preprinted' etc.. 
It's something like that, I'm after. That's better than specifying 
tray, but that can be done also. I'll investigate further and put 
it in the dialect.

REBOL PostScript Dialect v. 0.4.0 released: http://home.tiscali.dk/john.niclasen/postscript/postscript.r

Documentation here: http://home.tiscali.dk/john.niclasen/postscript/postscript.html

Added MediaType, ManualFeed and MediaPosition to control paper selection 
(tray). Also made Courier font ISOLatin1 encoded. And better PS comments 
in the output according to PostScript Language Document Structuring 
Conventions Specification.

It's now possible to produce PostScripts documents, where the first 
page is taken from e.g. tray 2 holding Letterhead paper and the rest 
from e.g. tray 3 holding Plain paper.

I suggest, people use MediaType to select paper, and only use MediaPosition, 
if MediaType doesn't work on the printer.

What is the difference between the postscript dialect and PDF one? 
It is just that you can write directly to printer?

are those dialects a bit compatible, or completly different syntaxes?

I haven't studied the PDF dialect. PostScript and PDF has two different 
goals: http://www.adobe.com/print/features/psvspdf/

reading your Synapse link reference - actually that is the quesiton 
of POV, for me the first paragraph has completly reverse meaning 
"The advantage of using PostScript is that Synapse EMR can display 
them nativey, and does not use PDF for printing.". I think that most 
ppl and platforms do have PDF Reader of some form, which means - 
I've got a preview mechanism, avoiding user to easily modify the 
output.

I will read the link, thanks, hopefully I get different perspective 
on that ...

Shortly you can say, PS is a language (used by professionals describing 
output in a very precise way) and PDF is a document format.

the problem si the preview ...

pekr, the advantage of using the PS dialect is that it can be fed 
directly to a postscript printer. This enables printing in all versions 
of REBOL. PDF needs to go through an external PS conversion program 
to do the same.

is Tex and PS anyhow related? I have heard Tex is very precise too

Pekr: from the geomol's link: "A PDF file is actually a PostScript 
file which has already been interpreted by a RIP and made into clearly 
defined objects. These objects are viewable on screen not in code, 
but in visual objects that everyone can see."

TeX is a markup system, kind of like HTML. you can produce PS documents 
from TeX files.

Yes, it might be a bit difficult for end-users to preview PS (unless 
you use Mac OS X or the like), where PDF might be easier to preview, 
because "everybody" now-a-days has Acrobat Reader.

Henrik - 95% of everythin I want to print, goes via preview first. 
The need to install GSview or something like that is total problem 
(because of already current penetration of Adobe Readers, I regard 
it being a solved case :-)

PDF is nice for distribution, while PS is great for direct printing.

OK

pekr, of course you want to preview it. that's the current disadvantage 
of postscript.r, but if you are printing tonnes of graphical labels 
or cards, postscript.r is excellent for that.

something with clearly defined graphics, maybe with a few varying 
text fields.

the advantage of maybe not so precise PDF system comes into equation, 
once you need more abstract thinking, e.g. sending docs around, adding 
comments, electronic signatures etc.

Henrik - would it be difficult to create AGG based preview?

I tried and failed, but I might have used a wrong approach. Graham 
has done some PS previewing in a demo.

the problem is coordinate systems and that fonts do not scale linearly 
in AGG.

ah, yes, of course ... yesterday's talk here with Cyphre ...

PDF is basically a compiled PS document. Requires less "brainpower" 
to display.

The postscript dialect give you very precise control of the output, 
but it's also maybe too low-level for many jobs. Dialects should 
be build on top of my postscript dialect (where you don't think in 
PS coords), and that should be easy to preview with REBOL/View (using 
DRAW).

geomol, I think that it should be kept at a low level. This way I 
or someone else can build a library of standard things on top of 
it to generate formatted pages, tables, formatted paragraphs and 
such.

just installed Gsview - I thought it is much bigger. it seems fine 
...