World: r3wp

view layout [
	origin 0
	bx: box 400x400 black effect [
		draw [
			translate 0x400
			scale 1 -1
			pen red
			line 50x50 350x50
			pen blue
			line 50x50 50x350
			pen yellow
			line 50x50 100x200 200x150 300x250 350x225
		]
	]
]

but this won't work with text though because it would be reversed 
in Y axis too.

Another solution is to apply own translation function on the dialect 
block or generate the dialect block with translated coords from scratch. 
(this shouldn't be a rocket science and would work with text too)

Regarding text, maybe Graham is right and a graphics-only reverse 
would help? for diagrams. The current way is a bit complicated, until 
one gets the trick.

means "apply own translation function on the dialect block". And 
now that little reversion-math, y: high - y .

now -> know

that would require one step above parser to draw dialect, no?

It's really easy:

translate-draw: func [
	height [integer!]
	blk [block!]
	/local dr p
][

 parse blk [some ['draw set dr block! (parse dr [some [p: pair! (p/1: 
 as-pair p/1/x height - p/1/y) | skip]]) | skip]]
	blk
]

view layout [
	origin 0
	bx: box 400x400 black effect translate-draw 400 [
		draw [
			pen red
			line 50x50 350x50
			pen blue
			line 50x50 50x350
			pen yellow
			line 50x50 100x200 200x150 300x250 350x225
			pen white
			text aliased 10x350 "Y axis"
			text aliased 320x40 "X axis"
		]
	]
]

Looks like magic :) But should not be required to draw a line through 
some data?

rotate says it sets the clockwise rotation for draw commands.

So, why does the text move across the page ?

view/new layout [
		b: box 400x400 black effect [ draw []]
]

for i 0 90 5 [

 b/effect: compose/deep [ draw [ rotate (i) text vectorial "This is 
 a string of text 1" 300x75 ]]
	show b
	wait .2
]

because the text rotates around 0x0 rather than around itself

should this be changed?

which is what I figured you wanted to do. you need to make the text 
at 0x0, rotate it and then translate it to the position you want

e.g. translate 100x100 rotate 30 text "something"

or set up a straight line "spline" for the text ...

possibly

Well, seems to me it should be changed.

changed in AGG or in the code?

Text should rotate at the point where it is being drawn

in AGG.

boxes don't rotate around 0x0

why should text?

or do they ??

well, if you did that, how would you rotate around another point? 
I won't argue for one solution or the other, but this approach seems 
natural enough to me.

I think they do

which approach?

1. first you draw
2. then you rotate
3. then you translate

in classic REBOL order

which means start at 3. :-)

speaking of which, it could be fun to see a LOGO like dialect for 
DRAW. fun for the kids.

Gregg has one.

that's good. I don't have to do it then.

do you have to create the kids first?

got plenty of those around, not mine though. I don't know how interested 
they would be in it yet. I spent countless hours in COMAL80 when 
I was a kid drawing with the "turtle".

Comal80 - a Danish product?

I remember I had a Comal80 interpreter for my C64.

I don't remember what it was. I think it was for several platforms 
but I used it for my C64.

I think it was a great drawing tool. very straight forward approach 
to drawing.

then I got an Amiga and was exposed to the horror that was Amiga 
Basic.

I've got my graphing utility written now in my postscript dialect

just labelling the y-axis is a problem because of the way AGG does 
the rotate vs PostScript rotate command

and there's no way to save a graphic state in AGG.

ah, yeah that could be a problem

Graham, AGG rotation: that's just an effect of the way AGG does its 
transformations which apply to the whole image. The rotate command 
is just a shortcut method of specifying just the rotation angle of 
a transformation.

transform (origin) (angle) (scale-x) (scale-y) (translate)

What you want to do is set the origin to the centre of your object, 
then change the angle and translate as you wish.

I agree that it is a bit uncomfortable at first. I was also expecting 
something simpler like in flash, but I suppose this way is more powerful.

Anton is right. DRAW works on lower level than FACE so there is only 
one tranformation matrix per DRAW block (ie. it is applied on all 
rendered primitives). OTOH you have relatively wide range of commands 
how to control the transformation matrix or even use the mtrick stack 
to push/pop different trnasformation states to apply  nested transfromations.

(Note that due this lower-level approach the drawing is also faster.)