Re: SVG1.2 and web applications

"Fred P." <fprog26@hotmail.com> wrote in message
news:BAY2-F48cRGEvefCeac0002ee28@hotmail.com...
> - SVG Editor - Beta - look and feel:
>
>   1) Without JavaScript (for ASV6pr1)
>       http://j2k.sourceforge.net/svg/august8/btn_def19.htm

The thing that interests me here, is why you're not using the power of
vector, but making triangles with rectangles?  It makes look ugly when we
zoom!

> SVGTimer could be pretty useful.
> http://www.w3.org/TR/2003/WD-SVG12-20030715/#SVGTimer

Do you feel it's more useful than setTimeout/setInterval - does it allow for
things not previously available?  (not that they are suitable for a language
independant environment)

> Maybe a Socket Interface to TCP/UDP sockets?

I think Sockets are the only sensible (in addition to beefed up
getURL/postURL), then we can build our own solutions to any format we want.

> Maybe all this can be done via XML-RPC or SOAP support?

No!, we need sockets, and definately do not want to be limited to XML
solutions.

> BTW, SVG has no '\n' only multiple <tspan>, so things get a little bit
more
> messy. ;)

You have looked at the text-flow portions which solve this?

> Another thing, copy/paste to and from other application without using
"Copy
> SVG".  It's far from being 'transparent'.

Access to clipboard is generally frowned upon in the web environment, it's a
big problem in uniting web and non-web functionality, since to do good
integration, you need to provide functionality that you do not want with
untrusted resources.  The problem means you need to develop a security
model, as well as the functionality.

> HTML/XHTML,

SVG has loads to add to come anywhere near this... however the ability to
bind RCC or similar to render an XHTML in some manner would be useful.  The
important difference between HTML and SVG for me, is that HTML only defines
structure, whereas SVG mostly defines appearance, they're in a different
problem scope.

Jim.

Received on Monday, 18 August 2003 10:17:52 UTC