AltME groups: search

It's slow, but here is the US in SVG http://apps.arcwebservices.com/svgviewer/map.html

terribly slow... but nice source of data... that's good thing with 
SVG.. it's easily parseable

REBOL would make good use of Pcode, since it would still be parsing 
at the same level.  Yeah, saving the "State" of a vector render would 
in theory be very fast then.

There are a lot of not so well thought out things about SVG (or I'm 
missing it in some way).  For example, you "animate" at the object 
level.

In my mind it should be:

- Make list of objects.
- Group some of them.
- Animate by reference.

But SVG seems to be simply:

- Make an object, embed animation.
- Next object.

If you want Pcode for SVG, use one of the binary XML encodings like 
EBML. If you want Pcode for REBOL, that's what Rebin is to be.

Here's a breakdown for any encoding (Pcode, XML, REBOL, whatever):

Portability:

You need to build or acquire a decoder or encoder, and third-party 
code would need to as well. Advantage: XML


Faster execution: The main way you get that is to make the model 
of your data format match your data model. If the match is close 
enough you can translate the data to your internal model in insignificant 
time, like EBML to XML, Rebin to REBOL, or CPU instructions. If your 
internal semantic model is simple enough you can quickly do a direct 
interpretation of the data, like older Pcode interpreters or the 
original Java byte code, or the micro-operations inside modern CPUs.


In the case of REBOL, we have it easy because REBOL is primarily 
a data model. All we have to do is encode that data in an efficient 
binary format and then decode that format to the memory model. That's 
Rebin, the proposed Pcode of REBOL.


In the case of XML, it is slightly more difficult because there are 
competing binary encodings, and none of those will be supported in 
a web browser until it wins the format war. EBML is like a Zip for 
the XML data model, rather than its syntax (similar compression algorithm 
too) - much faster than unzipping XML and parsing it. The main problem 
is that only Matroska decoders support it right now - no web browsers. 
Similar constraints exist for the other binary encodings of XML.


In the case of SVG, we are much less lucky. SVG has its own data 
model on top of the XML data model. Once you decode the XML from 
whatever format it was encoded in, you end up with data of the XML 
model - then you have to interpret that data to get a dataset in 
the SVG model, much like the relation between REBOL and the Draw 
dialect. There may be some advantage to coming up with a Pcode for 
SVG.


The main thing that you need to keep in mind is that your Postscript 
experience is throwing you off: The semantic models of modern graphic 
formats are declarative, not programmatic - this was the main change 
between Postscript and PDF. A Pcode for a modern graphic model would 
not be executed like code, it would be loaded as data.

R, I doubt that Adobe has any committment to SVG now.

Graham - but if SVG is W3C standard, everybody will use it, no matter 
what, no?

SVG is widely implemented by those who actually pay attention to 
standards. That does not include the companies behind the majority 
of the content on the web: Microsoft and Adobe.

Adobe was supporting SVG before they bought Macromedia - now they 
have dropped SVG for Flash.

Please note that Adobe has announced that it will discontinue support 
for Adobe SVG Viewer on January 1, 2009.

AFAIK, Adobe has discontinued downloads of the SVG Viewer already 
:(

Interesting conversation on SVG ... perhaps it would be better to 
continue in the SVG Renderer group (or just rename it to SVG?) no?

IE needs the Adobe plugin to view SVG.  I believe but have not seen 
it working that FF has/were building their own viewer built in.

I don't agree, that "Flash is slow junk". It was very well designed 
for creating interactive animations. And it supports things, which 
SVG is missing... as for example possibility to cache vector drawing 
as a bitmap. If something is slow, in most cases it's not Macromedia's 
fault.

BrainH, I won't belabour the point, I'm simply still unclear how 
once can make REBOL really much faster by making byte-code from it. 
 But, perhaps someone will, and make a demo, and prove it to me in 
the future… I agree that Zip XML is not a solution, but unless the 
Pcode system for XML is built into the browser, I don't see an advantage 
there either yet.

I'll be the first to use both though, when they exist.

Ashley, yes, will move future SVG convo to group…

There is probably a lot stored in SVG (Scalable Vector Graphics) 
format. There's been talk about that format around here, I think.

W3C link to this from their SVG page: http://openclipart.org/cchost/

so there's a lot of clipart in SVG format, I guess. SVG uses XML, 
so it should be easy to import using my RebXML packet. Problem is 
to figure out content  of the format.

doesn't Cyphre already have an AGG SVG viewer

There is a "SVG RENDERER" group here.

how is the tiger demo done?
 Yes, it's just converted SVG file to DRAW dialect, nothing more.

Maxim, regarding this: "somehow, it seems like its missing a color 
blend mode selection, multiply, add, screen, etc. right now its a 
ramp which fades to 0 on each side, such that when two successive 
colors do not have any bit in common it creates an alpha channel 
premultiplication grey zone..."

blending is not a part of gradient definition, look at Flash or SVG. 
Gradients work the same as in Rebol inthis case.

Anyone come up with a nifty way to get the size of vectorial text? 
Something like size-text:

	size-svg-text draw 1000x1000 [text vectorial "Hi"]

QAD first cut:


size-svg-text: make function! [text [string!] font [object!] /local 
img size i] [

 img: draw size: 200x200 compose [font (font) text vectorial (text)]
	;	determine y
	i: length? img
	while [zero? img/:i] [i: i - 1]
	size/y: i / size/y + 1
	;	determine x
	i: mod i size/x				; x offset of last match
	repeat y size/y [			; scan each line

  repeat x size/x - i [	; start each line scan at point of last match
			unless zero? pick img (y - 1 * size/y) + i + x [
				i: i + x
			]
		]
	]
	size/x: i
	size
]

size-svg-text "Hello World!" make face/font [size: 24]

anyone started work (maybe even finished) some Draw ->  SVG converter 
?


actually, even the other way round would be usefull if the above 
isn't already tackled.

SVG -> DRAW in R3 
but not finished...

Input: 
http://sites.google.com/site/rebolish/test-1/lizard.svg
output:
http://sites.google.com/site/rebolish/test-1/lizard-rebol.png
code:
http://sites.google.com/site/rebolish/test-1/svg.r

------------------------------------------
GLASS Release 003 is here:
------------------------------------------
http://www.pointillistic.com/open-REBOL/moa/files/glass-r003.zip

----------------------------------------------------------
everything promised for this release has been done:
----------------------------------------------------------

-Editor style and associated text editor application (Cristoph)

http://www.pointillistic.com/open-REBOL/moa/files/tutorial-image-style.png


-Encap friendly single file version of ALL glass libs, usable just 
like if they where external files. (Graham)

-The encap version of glass is all packaged within its own .zip file 
inside the root of the distro,  to make it easier to get started.

-Image style (jocko)
-it also has a pretty cool image style demo app.

http://www.pointillistic.com/open-REBOL/moa/files/red-text-editor-v0.5.7.png

-quite a few nuts and bolts worked on here and there.

-reworked the folder structure a bit to make it cleaner (it shouldn't 
change much from now on), tell me what you think?

-Added original SVG files used to create icons as part of distribution

-Added a few reference glass-related images for demos and tutorials.

-windows have automatic title handling when you fill their labels. 
(shown in text editor)
-many libs have had their apis improved
-extensive HISTORY AND RELEASE NOTES in docs folder.

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

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.

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

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 !!!

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.

i think that feature (2 different centers) is not used that much.

In the lizard.svg example i gave, they don't use it, the 2 centers 
are always equal.

Ok, i finished with Radial gradients (less the impossible feature: 
2 different centers)


SVG use a matrix transformation to convert a circular radial gradient 
into an ellipsoid.

And you know what ? 

We can do the same thing with grad-pen which provides 2 scalling 
factors (grad-scale-x and grad-scale-y)

So in that case it's easier than for linear-gradient.
1/ take the focal point of the Radial gradient (fx, fy)

2/ Create 2 vectors starting from this point: 1 vertical and 1 horizontal, 
using the radius as their length.
3/ apply the matrix transformation on them.

5/ get  the component X of the transformed horizontal vector, and 
the component Y of the transformed vetical vector
6/ grad-scale-x:  x / r
7/ grad-scale-y: y / r

That's all folks

Guys, i updated the lizard.svg rendered with Rebol http://sites.google.com/site/rebolish/test-1/lizard-rebol.png

To compare with http://sites.google.com/site/rebolish/test-1/lizard.svg.


I'm glad to announce that i see absolutly no differences inside Google 
chrome.

All the grandients (linear and radial) are perfectly rendered by 
Rebol.

the difference in your render and SVG render is mainly the anti-aliasing, 
which is crisper in the svg renderer.... probably has a better algorythm 
setup than the one use by R3... this is probably manageable within 
AGG, but AFAIK there is no control for it within R3.

steeve is working on annimated splash screen logo animated in svg 
for the next version of viva-rebol :P

Nice work Steeve! I'm glad R3 gradient improvements in DRAW were 
useful. It shouldn't be a big problem to render SVG using R3 draw. 
Bigger issue is to be able to parse all the possible SVG content 
you can find on the net ;-)

My, my, my...


I think some features in SVG, are too much work to implement with 
Rebol.

1/ The "objectBoundingBox" units.

Which means, coordinates and lengths are ratio or percentages. 

And they are converted to real units depending of the bounding box 
of the shape on which they apply.
It's easy to calculate when the shapes are boxes or vectors. 

But when it comes with arcs or curves, it becomes a pain in the ass.


It's not a real problem because Inkscape for example has an option 
(simplify shapes) to convert all the ratio units in real units (ie. 
pixel units).

So, I don't see the interest to rewrite DRAW from scratch with Rebol.

(because it's what it means, to be able to calculate all the bounding 
box)

2/ Outlines with gradients


Those fullishs can specify a gradient for the pen attribute (which 
draw the outlines).
Rebol can only have a gradient to fill a shape.
It can be simulated by drawing the related shape 2 times.
1 time with the pen gradient.

A second time with the fill-pen attribute (which can be a gradient 
too).

But the second time the shape must be, at first, downsized of the 
line width.

To do so, it means that we need to know the center of the Bounding 
box of the shape.
So, same problem than 1/


3/ The fill-pen attribute (gradient or color) never apply on the 
outline of the shape, event if the outline has no color but actually 
has a width.

It allows SVG for example, to have transparent outlines.
We can't do that with Rebol. 

Because the fill-pen attributes (or the gradient) fills all the shape 
at first.
And then the outline is drawed over.

If we don't provide a pen color, or we provide a transparent color, 
we see the fill-pen content instead, at the place of the outline.


Perhaps, that can be modified in Draw. A nice request but not a so 
considerable feature to my mind.

(And it can be impossible to implement this in Draw, if AGG doesn't 
support it at first).

re 1/

yes, I don't think this is a problem of DRAW but more problem of 
unit conversion. DRAW works with pixels as it it low level dialect 
(not only for rendering SVG format). So the higher level code(SVG 
parser) should be responsible for this until I am missing something.


re 2/ gradients for outlines were planned for addition so I hope 
this will be in the R3 final release ;-)


re 3/ transparent outlines are known problem. (BTW is this working 
properly in other SVG renderers? I'd like to see the results) This 
is because we are using rasterizer which is drawing one shape over 
another. IMO solution could be to replace the rasterizer with different 
one (for example like Flash) which is simulating 'Constructive Solid 
Geometry'.

But this would need major changes in the current internal implementation 
(and in fact also switch to higher version of AGG). 

My guess is it could also speed-up the rendering in some cases...I 
started to investigate this area but it needs more time which I currently 
don't have :-/

That was an SVG converted to DRAW, but I'll see what I can find.

Henrik, have you the original svg files of the signs ?  I would like 
to see what i get with my parser.
If they are not public domain, don't give them ;-)

Steeve, sorry, it's a small hack. I grabbed the svg coords from inkscape 
manually and simply pasted them in a text file, made them pretty 
for rebol and converted them to DRAW in a simple way. I have no XML 
parser or anything like that.

bug you kept the original svg files, did you ?

just google "SVG icons", plenty of links :-)

Steeve this was one of my favorite file for testing of the R2 SVG-lite 
viewer:
http://david.bellot.free.fr/svg-cards/

Good luck! ;)

cyphre... those are incredible test SVG files!

and what  about the text display / font management issues ... and 
this can be linked to viva-rabol or SVG rendering... Cyphre do you 
plan or have taken  some notes about that area ?

now if only IE8 would have put SVG within the browser ... like firefox.

Not just the box model too -- SVG uses CSS for styling drawing objects.

I said it xy years ago, that it will happen. Nowadays browser is 
considered being "universal app container" ... the strange thing 
is, that while it provides crap speed (even with AJAX) compared to 
native apps, ppl are forgivable here. But - in order for browser 
to keep its chances, we need to keep the standards. Looking at W3C 
and all its MLs, I wonder how cross platform, cross browser support 
goes. There are technologies for multimedia like SMIL, etc., SVG 
- crappy supported.

We turned the system from low level clean gob design to single-gob-SVG 
renderer ...

Carl wants some icons, so I'm trying to build some for him now, hence 
all the SVG stuff.

I made it in SVG. I can't remember how I did the R, but I think I 
took an Arial Bold and made some adjustments.

Geomol, I made a very primitive SVG importer for R3. it can only 
handle one shape in one color, but it's nice if you need to draw 
it by hand. If you need it for complex shapes, let me know.

of course.. zooming and SVG night be another method :)

Well, i only wanted construct a block of tags and strings.
So i came with that, it's enough for me currently.

src: read %frog.svg
out: []
parse src [
	any [
		copy str to [#"<" | end]
		opt [if (not empty? str) (append out to-string str)]

  not end src: (set [data src] transcode/next src append out data) 
  :src
	]
]

I'm trying to build a svg converter (yes another one, but for R3).

As you can see here http://sites.google.com/site/rebolish/svg, it's 
pretty decent for the frogs (Rebol draw version at right)
But for the lizard, there's missing something, gradients.

But i'm stuck with the speciifications of grad-pen http://www.rebol.net/wiki/Grad-Pen

I don't  know how to build it from http://www.w3.org/TR/SVG11/pservers.html#Gradients

can grad-pen do all the properties of SVG gradients that you need?

Btw, doing my SVG renderer with R3, i can't convert my drawings into 
images, it's crashing.
Using the draw function or to-image as well.

I can post a bug, but i don't know what's the problem because it 
depends of the drawing. Sometime it crashs, sometimes not.

Is it possible for Cheyenne to support SVG?
I tried:
response/buffer: {<svg></svg>}
response/set-header 'Content-type "image/svg+xml" 


but failed.   double string was returned. "<svg></svg><svg></svg>"

You're using a literal string as response, you should try to add 
a COPY in front of it to avoid side-effects: response/buffer: copy 
{<svg></svg>}. Even better, as you're in a templating system, make 
it a template:

<% response/set-header 'Content-type "image/svg+xml" %>
<svg></svg>

i'm interested too (cause i already made a partial svg converter 
for R3 ,see http://sites.google.com/site/rebolish/test-1)

But i'm afraid i will be disconnected from rebol stuffs during comming 
weeks.

 AGG group about a bug in TRANSLATE

. henrik not a news that bu exist since 3 years i submited it long 
time ago when i was implementing matrix translation in AGG when i 
was writing SVG renderer. So far no one seemed to care about that...

dunno about HTML5 Canvas, but browsers contain SVG, and there were 
some attempts to do REBOL-2-SVG converters. There was some incompatibility 
in how gradients are specified, but that could be added to our kernel. 
I am sure Cyphre has more to say here ...

it embed an SVG engine ( even if i'm sure a rebol / agg one blast 
it ) support of freefonts  support of png (but only this image format 
where rebol works with jpg etc...)

with rich text come a lot of  troubles like handling paragraphs resizing 
things etc... how and where images are inserted withing the text 
paragraphs etc ... Can at some point the image inserted within text 
can be a draw set instruction rendering (for graphics or SVG image 
rendering ) etc... how will that engine grow ?

but the material (gradient) is still represented by draw, right? 
I mean - there is no chance for designer to e.g. use some gfx tool, 
to create some nice material, as it is not convertible to AGG, right? 
Or would there be any way, via SVG for e.g.?