World: r3wp

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?

I would like to know when the problem with Agg Matrix will be solved 
and when Carl plans to integrate in REBOL/AGG a radiant function 
that can better feet with SVG datas  ? I started 3 month ago an SVG 
engine and since then I'm stuck because of those 2 problems... SVG 
without transformation matrix and without gradients it's like nothing 
.... ( see greoup SVG renderer for more informations and test code)

shadwolf: please see my reply in 'Carl Only' group.

It's 1:04AM here, not a time for serious work, so I'm fiddling little 
bit with some eye-candies in new DRAW and I must say it's SO powerful. 
I'm just starting to see the potential...whooo! Thanks

ft: make face/font [size: 60] 
view center-face layout [
	origin 0
	box 400x80 white effect [
		draw [

   fill-pen linear 0x0 0 100 30 1 1 black white black white black white
			font ft
			text 0x0 "Wavin' REBOL" vectorial
		]
		emboss
	] with [
		rate: 0
		n: 0
		feel: make feel [
			engage: func [f a e][
				f/effect/draw/3/x: n: n + 2
				show f
			]
		]
	]
]

That's very cool.

Wow. Can you made an animated gif from that? :)

'save doesn't support GIF, so I doubt it... Unless, of course, someone 
who understands GIF files hacks something together  >.<

I guess Kru can save multiple images and use some external converter? 
:)

Or that.

Cool Kru! :-)

thanks :)

In the new DRAW dialect, should SCALE have influence on LINE-WIDTH?

that is a very hard question, because in most vector drawing apps 
it doesn't, while it is also arguable that it should.

also, i don't know if AGG is able to scale a line width if the scale 
is not the same for x and y.

That seems like a frustrating issue.

Cyphre thank you for your answer You need more infos on Gradient 
here is the official webpage on the topic hopes it  could help you 
to make a svg gradient complying fonction in draw  ...:)

http://www.w3.org/TR/SVG/pservers.html

Cyphre there is no missing thing in AGG  gradient the coordinate 
datas given by SVG gradient data block is different. To make it short 
and simple SVG work with area pourcentage of filling (what ever the 
 size of the area to colorize is you will allways have red 20% blue 
40% black  40% if red blue black are your 3 colors that are used 
to make the gradient effect) Then we have a vectorial information 
that  give the orrientation of the gradient effect. SVG gradeint 
are linear, circular or parterned (in most case linear is applyed 
...). REbol AGG gradient use area offset you have a start offset 
a end offset and the  colors are degraded along this vector  nothing 
more nothing less you have no area coloring infos. This is if  my 
recalls are good the differencies betwin AGG gradient and SVG gradient.

and the proposed solution is? Can we have some helper parameters 
in rebol AGG to allow SVG kind of parameters? Are AGG gradients subset 
of SVG? Is there 1:1 equation, so that we can transform between the 
two? Maybe the problem is a bit more complex?

Pekr and the solution proposed by Cyphre  was to insert to agg in 
built fonction complying with SVG datas ...

yes, that should be enoug, no? If Cyphre can use AGG internals to 
simply make it working, so he will, no?

Pekr yes we can do adaptation but this will enslow dramatically the 
SVG rendering. My goal is to make a SVG widget capable for REbGUI 
 to dispaly graphic content like tool bars, logo etc so faster is 
the render better it's

he can create e.g. gradient-svg command ...

I am not talking about adaptation in rebol level code, but directly 
in rebol AGG layer = C code - that should not be slow, no? Cyphre 
would then expose it via e.g. gradient-svg new command ...

we have e.g. new natives for rgb-to-hsv and hsv-to-rgb already ...

yes that was what he had in mind and that perfect feet my need  ^^. 
But he asked me in Carl's only  group some more detailled informations 
about SVG way to handle gradients. Th'at why i give him the link 
to the gradient SVG official documentation and why i make this simple 
explaination ;:)

it was simulated in rebol level, was found being slow, so Carl reacted 
upon the request and made those functions native, as they became 
usable for us ...

yes the actual svg render have been made in one week it's pretty 
fast and the code is very tiny ( 400 lines for a svg to AGG/Vid rendering 
engine that not so mutch  ^^)

basically SVG is a XML  structure but for several reasons i choose 
to pass thru a XML 2 Object converstion and then I  treat the SVG 
infos converted to rebol objet structure ;)