World: r3wp

I'm hard working on the matrix support ..

and I'm close to have found a solution to one of my problems regarding 
to the transformation matrix

Features still on the work table are:
- SVG Transformation translation (mostly matrix)
- SVG Gradient translation (linear partern radiant)

- SVG drawing primitives (some drawing primitives are not supported 
actually ) 

- SVG Animation translation (don't know if this is a usefull and 
suitable fonctionnality tellme what do you think about it)

FYI: 

Ed Pegg writes "I did a survey of all available vector-based drawing 
programs, in anticipation of SVG in the 

next Firefox. I found 29 different vector drawing programs. Of these, 
14 were free or open source. More than I 
expected. Did I miss any good ones?"
 

http://developers.slashdot.org/article.pl?sid=05/08/02/0117224&from=rss

Good list ;)

personnaly I'm working with InkScape a very good SVG software...

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.