World: r3wp

For ppl interrested in  SVG rendering engine. My  tonight work  and 
 test on the engine   is resumed in the AGG topic. To resume before 
matrix bug as causing bad scale and bad position.  Now we have good 
position but still bad scale  i post screen cap samples and we can 
see that the evolution is good  betwin View 1.3.1 and 1.3.2

transform problem are on their way to be solve gradient too by cyphre 
and  Carl those  two things are the most blockant problems until 
they are not completly solved we can't expect to have a full working 
SVG rendering engine  -> most of SVG  imagines use transform effects 
and gradients this means    that if we want to get a pretty good 
and reliable SVG engine we have to fixe those two issue. SVR rendering 
engine is a good and hudge test upon AGG integration to REBOL/View 
and it allows us to embetter it !!! 


Once we get a fully working engine with basic human understandable 
algorithm i will start the  optimisation process using  parse (but 
to be franck i don't  know how parse will react in front svg row 
data or how will be the time to dev this parse based SVG engine ... 
 in all cases I think the actual engine have teached me a lot arrounf 
the SVG to AGG adaptation process so i hope the translation to parse 
and parse/rules will not be too hard and too long)

well last thing i can say is that SVG rendering  engine is very high 
on my task  list ( task number one) i worked on the adding of some 
other new drawing primitive  (image rect, circles). I will continue 
to  work on the close support of all SVG datas that can have a meaning 
in AGG context. SVG rendering engine is  a   2   weeks of work only!!! 
... until i fall on the gradient and transforms problems so this 
ensure us advancing on this project will be very fast once we solve 
bugs in REBOL/View related to AGG (wich is in progress actually)

I still take as SVG workshop / reference software INKSCAPE  pretty 
good LGPL  sofware available for  all OS.

In the futur i hope we will use a lot svg in dynamic  drawing composition.

Well done, keep up the good progress! ;)

ty ashley   ^^ time i wasn't giving notice of my progress but mainly 
because Gradeint and transform problem where dependent on AGG an 
not on my  script.

but this not means i'm not anymore interrested by the project or 
that the  project is dead. I found like you pretty hudge hopes on 
the integration of High scalable grphics in rebol  ^^

for me to be honnest the advantages of  using SVG instead of images 
 are a lot this is a quick list of my thoughts on what can be done 
with  SVG format.
 - easier embeding of graphical content
- resizing auto ith not grphics quality loss
- cheap but sharp skining 

 - graphical content of an  User  Interface  very low because rebol 
 is pretty able to  work with compression of text content ( compress/decompress)

A little sample to enlight this  compressed SVG file with blender 
logo ->  less than 500 octets (any size can be applyed with no graphic 
loss (aliasing, color loose, blur, pixelisation etc..) )  a fixed 
jped for same content will use  around  50ko. This means less datas 
in memory to as graphic pixel tables are very heavy in VM memory

- Dynamic graphical content. some thing like text scrolling or efffect 
like Flash ones but with  a  reduction of  1000  of the data and 
memory use SVG use a labeling system for  each graphical content 
that compose the image we can provided a tiny system to handle easy 
animation and show/hide of graphical content using raw rebol commands 
-> this will make pretty easier the realisation of dynamic animations 
in rebol ViD content and  as any REBOL/View face is DRaw/AGG capable 
the effects that we can create isn the futur with this idea will 
have no limits  -> this means too to have a pretty fast and ell designed 
SVG engine (that's my actual path on research)

One other big advantage is that there is a lot of high-quality SVG 
in the public domain, and it's growing fast.

Ashely when are you updating RebGUI?

When I find some spare time. ;) Next week or two hopefully.

shadwolf, a good example to use with your svg renderer is the word 
map with political borders (public domain license) http://www.mappinghacks.com/maps/world_borders.svgz

Joe hum inkscape is not able to show this svgz file that's strange 
 ...  I will try to investigate why this happend ...

surfing around on internet i found another common application for 
SVG -> graphs representation. The idea is inspired by  a ruby project 
http://www.germane-software.com/software/SVG/SVG::Graph/#N10034. 
To do this in rebol we need teh ability to save data in an image 
PNG. The way we can use a thing like this could be to use a simple 
rebol draw based dialect to write  the graphs if we are in REBOL/view 
application the  graph is isealy shown if we need to show the  graph 
in webrowser we can have  2  external sources SVG  and PNG.  For 
importing graphs from another application the SVG is the best way. 
 So our REBOL::SVG::GRAPH would be able to import graphi content 
from a SVG file, output SVG and PNG files, render graphs to REBOL/view 
draw pane, propose a simple way to implement graphs  using a rebol 
dialect.

hum new rebol/view have save/png hability woooooooooooopy so there 
is nothing that prevent us to make a  graph /AGG/SVG/PNG  dialect 
 ^^

if some one is interressed to make it and need informations i'm ready 
to help  ^^

View 1.2.1 has save/png, it's not very new...

Anton i discover it recently  ^^

so for me it's new lol but more serriously until AGG was not available 
i think the use of save/png to-image was really not meaning

on a project like an svg graph system save.png take really all it's 
sens imagine a way to make easyly graphs with your rebol GCI to display 
graph stats in your web pages for example

as svg or as png in a simple and easy way

you have that in php and in ruby or php for example why not rebol 
starting from the point that rebol dialectal ability is incredible 
it's a pitty to not take advantage of it  and show ppl hat rebol 
can apport on this particular application and this gives a good way 
to compare rebol to the other scripting language

some thing like

graph [ line "apple" red  5 12  12 8  line "banana" green  1 2 3 
4 6 ]

would be fun i think

.

would following news help us to get AGG - SVG compatible gradients? 
It regards AGG 2.4, new branch of AGG, and I am sure we will get 
it ported to REBOL too ...


New utility class template is added, gradient_lut. It allows you 
to easily create a color LUT for gradients from a set of color stops 
as they are defined in SVG, section Gradients and Patterns.

If any person is interested in developping graphs in Rebol they may 
find the following links of interest: www.combinatorica.com which 
have the source code in mathematica for calculating graphs and depicting 
them.  There is also the C library at www.graphviz.org and the many 
little languages drivers.

sur i  do  ^^

okay  thank you for the  link  in my  idea  my  SVG/REBOL graph render 
should be easy to  use and render basical graphs  using  a psecial 
graph dialect  but  ofcourse it  will be enhanced afterward...

Oh my, SVG, what a pain...
Some strange bugs, i can't figure...

As you can see here http://sites.google.com/site/rebolish/test-1/lizard-grad-err.png

I've got some problems to map correctly the gradients on the shape 
they are supposed to cover.

i can't figure why the coordinates of the gradients in the SVG file 
are wrong.

It's not clear (http://www.w3.org/TR/SVG11/pservers.html#Gradients) 
where the gradients should start....

I've been playing with Shadwolf/etc SVG 06 svg renderer today and 
am at the point where i am working on linking in gradients.  The 
test SVG i am using (because it seems to be a good mix) is http://en.wikipedia.org/wiki/File:SVG.svg

Icarii, your svg file is too much complicated for me.

It's using both gradientUnits="objectBoundingBox" and gradientUnits="userSpaceOnUse" 
 to render the gradients.

userSpaceOnUse

 use real coordinates for the vectors used by gradients (what i do 
 currently).
objectBoundingBox

  use % vectors which have to be converted into real unit,  depending 
  of the real size of the object (after rendering) where the gradient 
  is applied (what the fuck  !!! it's magic).


I have enough pain to construct correct gradients in real units for 
the moment.Your svg file is too much complicated.

Currently my problem is with the linear gradients when a matrix operation 
is applied on them.


The linear gradient use a vector v = (x1, y1) - (x2, y2) to indicate 
his direction and length.


grad-pen is defined like this:  [grad-pen linear normal xy 0 len 
angle [... stop colors]]

And i calculate his values with:

- xy = (x1,y1)
- len =  length of the vector v 
- the angle of the vector v


When a matrix is associated with the gradient, i multiply the coordinates 
of the vector v by the matrix before calculating the other values.
It's working well when the gradient is vertical or horizontal.

But when the gradient is inclined , the matrix multiplication give 
a wrong vector and i don't know why.

To be precise, the resulting vector seems to have the correct position 
and length, but a wrong angle.

what sort of output are you getting for the angle in the grad-pen 
call?

Well, assuming you got x1,y1,x2,y2 from the Lineargradient

I calculate the angle like that:
arctangent (y2 - y1) / (x2 - x1)

As i said previously, the angle is correct when there is no matrix 
transformation on the gradient.
I compare the rendering with what i see in Inskape.

the svg i test currently (public domain) http://sites.google.com/site/rebolish/test-1/lizard.svg

And what i got with rebol: http://sites.google.com/site/rebolish/test-1/lizard-rebol.png

the gradients still have the same problem

when matrix transformations are applied, some are wrong, but hey 
! Quite a good result already !

Well, i think i got it for the linear gradients...

btw the bounding box call in the second sizing mode can be gotten 
from the size of the canvas you are drawing to.

Steeve - your work is quite impressive! Just don't become demotivated 
by possible lack of responses :-) If you find some bugs, or you come 
up with some ideas of how to make View more SVG friendly, write your 
notes down, we can discuss it with Cyphre. I think that we are still 
in rather initial phase, so we can e.g. change the way of how e.g. 
gradient-fills work (I do remember someone reported that you can't 
translate gradient definitions between /draw and SVG)

This matrix must not be applied on the gradient's vector as-is, but 
on something else.
And i found what, at least...


The documentation of SVG is lacking of a good explanation about this 
curious matrix transformation.
All we can read is that curious sentence:


When the object's bounding box is not square, 
the stripes that are 
conceptually perpendicular to the gradient vector within object bounding 
box space 
will render non-perpendicular relative to the gradient 
vector in user space 
due to application of the non-uniform scaling 
transformation 
from bounding box space to user space

What does that mean ?????


It means that the SVG gradient must be rendered without using the 
matrix transformation.

And THEN the transformation matrix must be applied on the resulting 
strips.

You see the problem ?

The matrix must not be apllied on the gradient's vector, but on the 
resulting strips produced by the use 
of the initial gradient's vector.


What foolish morons have designed such a complicated way of constructing 
gradients.

Can't they just give a matrix that can be applied on gradient's vector 
as-is, no they can't, it's to simple.
Morons, I said !!!


Because of that i had to make more transformations to obtain the 
REAL vector.
step by step I do something like that:


1/ Take the initial gradient vector V and apply the matrix on it, 
it gives a vector V1

2/ RE-take the initial vector V, rotate it of 90 degrees, apply the 
matrix on it, and rotate back the resulting vector
. It gives the vector V2

3/ Project the vector V1 on the line V2 (orthogonal projection). 
It gives a third vector V3.
4/ That's all, the REAL vector to use for the gradient is V3.


It take me a while to figure that, by analysing the Inkscape rendering. 
Morons i said !!!

I show you that part of my code...

		switch type [
			linear [
				unless x2 [x2: x1]
				unless y2 [y2: y1]

				if matrix [

     ; ** apply the matrix on the vector rotated of 90°, then rotate it 
     back,  give the vector V1
					set [y1' x1'] mulm y1 negate x1 matrix
					set [y2' x2'] mulm y2 negate x2 matrix
					x1': negate x1'
					x2': negate x2'

     ;** apply the matrix on the initial vector, give the vector V2
					set [x1 y1] mulm x1 y1 matrix
					set [x2 y2] mulm x2 y2 matrix
					;** project the vector V2 on the line V1
					set [x1 y1] project x1' y1' x2' y2' x1 y1
					set [x2 y2] project x1' y1' x2' y2' x2 y2
				]
				angle: atan2 x2 - x1 y2 - y1 
				if units = "objectBoundingBox" [
					x1: box/1/x * x1
					y1: box/1/y * y1
					x2: box/2/x * x2
					y2: box/2/y * y2
				]
				out as-pair x1 y1	;** offset
				out 0				;** start rng
				out square-root add x2 - x1 ** 2 y2 - y1  ** 2	;** stop rng
				out angle			;** angle
			]
...

Well i thought SVG 's radialGradients will be easier. I was wrong.
SVG Proposes another stupid feature (yet another one).
Actually they can specify 2 circles.

One where the gradient is really rendered. And another one used as 
a window which clips the first one.
What the heck is that !!!!

it's why in a SVG's radial gradient, there is 2 different  centers 
 (cx, cy) (fx, fy)  for the 2 separated circles.


When the 2 centers are equals, then there is no prolem to render 
it whit the rebol's radial gradient, easy.
But when they differ, it's impossible.

I can't blame Rebol to not allow that, because it's a really stupid 
useless feature.

Now the question is - should we adapt, or do we create copy of such 
functions, to allow being compatible?

I'm angry, i don't see why grad-pen in Rebol should allow such stupid 
feature