Vector Images and the SVGL stack

[-hh]

> R.G. wrote:
> 
> The difference between a true Bezier object and emulating Beziers with 
> polygons is resolution.

I see it like this, a little bit different.

A "true" Bezier object is a mathematical model, for thinking and abstract computations, but not realizable in our deterministic world.

The graphical output for such an object is **always** a raster of points, an approximation by a polygonal line ("emulated" in your terms) no matter if SVG, HTML5, postscript/pdf or LC give the input. If you look at the output with a microscope you still see the pixels of Super Mario.

In LC you have to give the raw list of points, the others above use for short the mathematical model *as abstract description* for the raster they wish, that is then 'optimally' prepared for the device by algorithms of the library.

So the difference is for me nothing more than the method of giving the directive to the CPU or graphics processor, supported by a more or less large library. In LC you have until now to write the algorithm by yourself.

So, of course you are right that such a library would be comfortable.

> B.S. wrote: 
> 
> I'm not saying Postscript can be replaced by SVG, it just seems like a poor man's alternative. LC will likely never support Postscript graphics because it would require an interpreter, which would cost extra and burden the rendering engine when used.
> 
> Now on the issue of things like blends and text within graphics I can see how supporting SVG in the engine would be a benefit as opposed to having to convert an SVG to something LC understands.

First of all. For both of us is postscript/pdf the non-plus-ultra, I suppose. But I use it (the "raw" edit) only for very special work.
I'm an ordinary LC user, use LC for a large part of the daily life, that's it. If I wish to have more complicated things then I can use (faster) other apps.

The HTML5 branch is a promising way, simplest to use via the standalone builder. And as HTML5 serves also SVG it may be better to support direct HTML5 calls (do myScript as HTML5script) in the engine.
Modern browsers have the SVG support already implemented and will do it for us.
So supporting (the small part) SVG in the engine doesn't make sense for me, ALejandro's way is the more applicable one,
for me -- everybody as he likes it.