World: r3wp

SVG matrix (a b c d e f) -> AGG scale [a d] rotate [b c] translate 
[e f] can I do this ???

matrix is 3X3

like that :
[a c e]
[b d f]
[0 0 1]

where couple AD = scaling BC= rotating EF = translating

Can't 'transform be used for doing all that ?

Dide, perhaps at work you have not updated your reboltech index.r 
file for a while, and it still points to my old rebsite.
Try this at work:
	load-thru/update http://www.reboltech.com/index.r

It was probably that ;-)

Don't know if transform REBOL/AGG command can do this 

I not enoght skilled in AGG to answer ... I will try to use transform 
instead of matrix

it's yet a kind of miracle for me totally noob in AGG and in SVG 
to have arrived to the actual point of the svg renderer. Lot of code 
and ideas have helped me a lot Ashley is trully a idea fountain. 
Those idea only claim to be worked again and again to arrive to a 
very very good and usefull tool

Transform does rotation, scale and translation in one command :
TRANSFORM       angle [decimal!]
                center [pair!]
                scale-x [decimal!]
                scale-y [decimal!]
                translation [pair!]

shadwolf: you cannot use partial matrix blocks on SCALE/ROTATE/TRANSLATE 
commands.

The problem of converting back already defined transformtion matrix 
is that you don't actually know what opearations(rotate,scale,translate 
etc.)  has been applied on the matrix values. ie transformation matrix 
is ireversible.

So I think there is no method how to 'extract' translation, rotation 
and scale from matrix content(correct me if I'm wrong)

I agree with you, there needs to be some sort of record on how the 
operations occured. I think there is big number of combinations (rotation, 
translation and scale). That could produce the same matrix, so decomposition 
is not easy if the only think know is the Matrix itself.

It all depends on the order of the single tranformations. So you 
need to keep track of the applied tranformation matrices and the 
order of tech transformation, than it's possible to derive the inverse 
tranformation.

Agreed.

yes, that's why the new DRAW dialect has PUSH [ ] command. It 'stores' 
the current transformation matrix into internal matrix stack. You 
can apply other transformations in the PUSH block or even reset the 
current matrix but after 'leaving' the PUSH command block you have 
active back the 'stored' matrix. Very handy for nested transformations.

So there is no more POP command ?

I thought matrix was only a way to merge scale rotate and translate 
values...

Cyphre have you an idea when the bug with matrix will be solved ?

same 4 gradients :) ?

Didec work like a layer difinition and manager

Using push the matrix or other trnasformation information are apply 
only on the push  block content. outside the push block the matrix 
informations are not affected

If I use TEXT I can specify the offset. Is there a way to specify 
the size as well and that the rest is clipped?

not afaik, but i think you could use the clip command.

Hm... but I don't know how big a text will render. And I can't referr 
to the text to clip it.

I have a feeling that draw TEXT is still using old draw code, and 
not merged so well with AGG yet.
I noticed that draw text offset doesn't scale:

view layout [box navy effect [draw [scale 0.1 0.1 text "hello" 40x40]]]

I also noticed line-width doesn't scale:

view layout [b: box 200x200 effect [draw [scale 1 1 pen 192.0.0 line-width 
32 line 10x10 190x190]] scroller 200x20 [b/effect/draw/scale: b/effect/draw/3: 
face/data show b]]

No luck using TRANSFORM instead of SCALE either:

view layout [b: box 200x200 effect [draw [transform 0 0x0 1 1 0x0 
pen 192.0.0 line-width 32 line 10x10 190x190]] scroller 200x20 [change/dup 
at b/effect/draw 4 face/data 2 show b]]

More weirdness with scale, line-width and arc:

- a 360 degree arc doesn't quite make it all the way around (small 
section missing at the join)

- arc loses its resolution (arc becomes an obvious polygon approximation 
to an arc)

view lay: layout [

 size 500x500 backeffect [draw [translate 250x250 scale 0.2 0.2 line-width 
 1 circle 0x0 300]] 
	scroller [change/dup at lay/effect/draw 4 face/data 2 show lay] 
	scroller [lay/effect/draw/line-width: face/data * 100 show lay]
]

(I showed circle, but 360 degree arc looks the same)

arc 0x0 200x200 0 360

text-size: you can use size-text. setup a face with /text, font and 
nothing else, get the size, use same text in draw.

anton: you need to use text vectorial if you want to apply transforms

robert: then you can't use draw.

Gabriele: great! Thankyou. :)

rebol [
	date: 24-Jul-2005 
	author: "Anton Rolls"
	comment: {

  Investigating why adding/removing 'merge from effect block seems 
  to change line-width on
		arc, circle etc.:

		ToDo:
		  - try to 

  - It looks like the AGG anti-aliasing is with the default window 
  background color ?

    When MERGE is added, then it's with the actual color that is merged 
    (seems ok and good to me).

    - so try to set b1/color so it's the same as the color anti-aliased 
    against in the merged version

    Perhaps default window background color (200.200.200) is close to 
    the default agg anti-aliasing color ?
		  (do not use custom window color)
		- try a simple LINE
		- report to RAMBO or AGG group
		- submit to RAMBO


  This shows that the addition of 'merge seems to add 0.5... (?) or 
  some scaled factor to the line-width:
	}
]

effect-blk: [
	draw [
		pen black
		line-width 0
		translate 25x25
		scale 1 1 
		circle 0x0 24 ;arc 0x0 24x24 0 270
	]
]
make-2nd-effect: func [/local result][
	result: copy/deep effect-blk
	insert result 'merge

 ;result/draw/line-width: result/draw/line-width - 0.5 ; <- even with 
 this they don't look quite the same

 result/draw/line-width: result/draw/line-width - any [attempt [correction-scr/data 
 * 0.1 + 0.5] 0]
	result
]
refresh: does [
	b2/effect: make-2nd-effect
	show [b1 b2]
	big1/image: to-image b1
	big2/image: to-image b2
	diff/image: xor big1/image big2/image
	same-txt/text: join "same? " big1/image = big2/image
	show [big1 big2 diff same-txt]
]
view/new window: center-face layout compose/only [
	across
	label 80 "scale"
	scroller 200x20 with [data: 1][
		change/dup next find b1/effect/draw 'scale face/data 2
		refresh
	]
	return
	label 80 "line-width"
	scroller 200x20 [
		b1/effect/draw/line-width: face/data * 4
		refresh
	]
	return
	label "line-width correction"
	correction-scr: scroller 200x20 [
		refresh
	]
	return
	b1: box 50x50 [refresh] effect (effect-blk)
	b2: box 50x50 [refresh] effect (make-2nd-effect)
	same-txt: text 200
	return
	big1: image 200x200
	big2: image 200x200
	return
	diff: image 200x200
]
refresh
do-events

I just took a look at Zeta (the BeOS clone) and saw that they use 
AGG for the rendering system. Nice.

Yes, I have proposed it for Syllable, as well

What's the likelyhood, or possibility of a PDF renderer now for View/Agg 
?

I'm sure fonts would be the major obstacle, as it would be for SWF 
viewing?

It seems Carl wants to integrate FreeType, so that would remove the 
fonts obstacle

By the way, our video expert evaluated several drawing libraries, 
among which AGG and Cairo, and deemed them unsuitable for the Syllable 
graphics system

I don't know his reasons in detail, but he's working on adding window 
backbuffering to the video driver framework. The few higher-level 
drawing functions that we have now, like drawing lines, are going 
to be tightly integrated into that

AGG could still be ported to Syllable, but I guess, being a crossplatform 
library, it would have lower performance

Kaj, I was thinking more embedded fonts -- would the author of a 
viewer need to parse the embedded font data before passing them to 
FreeType?

What about pdfs that are the output of scanners and pdf printer drivers? 
 Presumably these are just images wrapped inside a pdf ?

Yes, I think you have to extract font data to pass it to FreeType. 
But FreeType interprets the font data itself, so how hard could extracting 
it be?