It's great to see more SVG libraries arriving and SVG.js and Pablo.js look like interesting new tools.
While tools to dynamically generate SVG are needed sometimes the big future of SVG is artist-created images, so we generally in need of ways to manipulate , animate and add-to existing existing SVG images. SVG markup is already a better: clearer, faster, more embeddable way to create SVG images. Our tools should focus on adding value to the markup.
I use a lot of SVG these days and, sadly, SVG has to come with caveats. It currently performs terribly on iOS devices (especially large, detailed images) and there is no way to create progressively detailed svgs or mark areas for baking. Webkit did have an SVG scrolling bug where svgs were constantly repainted but, thankfully, that is fixed now.
Another gripe is SVG drawing tools. I am using a rather strange hodge-podge of a workflow (especially as I am a Mac user). Microsoft Expression Design → export as XAML → translate XAML to SVG.
It's actually quite effective / sensible for a few reasons 1) Expression Design is now a free download 2) XAML and SVG are very similar so the translation is reasonable straight-forward 3) Expression Design gives accurate pixel previews (and I have a second SVG testing tool that can flick between SVG and PNG to see where there are problems).
My tools are written in Go and may be of use / interest to other people. Let me know if you'd like to try them (caveat: they are one-user-one-developer-tools — me — so there is a layer of polish missing that I am happy to live with but you may not) and I'll work out how to upload them to GitHub.
Did you try WebCode (http://www.webcodeapp.com/)? It is a vector drawing app for Mac that instantly generates nice, clean and readable SVG code. You can also choose to generate HTML/CSS and JavaScript/Canvas code from your drawings.
I keep meaning to but haven't got round to coughing up the £35. It does look amazing and is (one direction) of the sort of thing I was talking about. I'd need to see the javascript it generates before I could happily include it a project.
Re: SVG drawing tools - why not Inkscape? It's native format is SVG and it allows editing the markup directly. I get much better results using it than converting XAML to SVG (which is JUST different enough to be annoying). Would love to see the tools you've written... Thanks for sharing.
I've had real issues with Inkscape, especially its user interface. It's just not a Mac app. I'd love to see someone tear the gubbins out of Inkscape and place them in a good user interface. (To be fair I have real issues with Illustrator's UI, too. And the App I choose to use isn't a Mac app to the point of being a Windows App on a PC in Parallels.)
Expression Design has a very simple, powerful interface: scroll is zoom, space bar is pan, unmodified click is select. I'd like to see someone make an SVG editor with a cross between it and Bret Victor's Gestural Zoom And Pan.
Yes, for example - even better, a big button with "See it in action" or something similar. What's important is to make it very easy to find something cool - that for a graphics library is very important. Good luck :)
I rolled a bunch of functions into a lightweight svg library a while back, haven't really updated it, but if the author wants some of my code, feel free to use it (it should be considered public domain'd):
part of what i did was to add into the prototype of SVG objects attributes that were getter/setter that you would expect, so the SVGCircle object, now has a cx, cy, rx, ry members. The advantage to this is that JQuery's animate() function has a secret ability to animate object members (I remember understanding why that was there at some point, but now I forget), so you could just use the $.animate() to get all of your animation done, even though those values are in the attrs list and not in the styles attr.
And, just to clarify: Some countries have no legal concept of "public domain" and even those that do, it can be unclear exactly how that impacts users of the code. A good license remedies that problem, and allows people to use the code.
MIT and BSD are "public domain"ish licenses, which have stood up to decades of scrutiny and usage by lots of projects. They'd be good choices. But, there are many others that also meet that description.
can't be bothered to, plus, I don't particularly like the MIT or BSD licenses (they're still licences, and you shouldn't need my permission). Sometimes, I put in a copyheart statement.
I also understand the liability part of the licence and I think it's disgusting: Limiting your liability by indemnifying yourself with a statement that no one is going to read, as far as I'm concerned, also means that you've lost. If someone wants to sue me for misusing my software then they can live out the rest of their lives as the miserable, tortured soul that they obviously are.
those countries that don't have public domain concepts are obviously putting themselves at an economic disadvantage - so they'll get what's coming to them. I only fear that we are headed that way in this country.
It's not just about removing the liability off of you, the author. A clear license also removes the liability of anyone using your code in a production environment that you may feel like suing someday.
We don't know you to trust you. There are plenty of people who are not decent and 'just trust me' is rarely reassuring. And you don't need to indemnify yourself in a licence. Poul-Henning Kemp doesn't indemnify himself with his beerware.
then don't use my code. In the end, what you do is your choice, but I'd rather not get the state involved in my acts of sharing - and that should implicitly suggest that I'm not interested in leveraging the state to take from you. If you can't trust that, then fine. I'm sorry for you.
It isn't that though, you are giving permission here quite clearly so if someone stumbles across this thread then they know some of the intention, however if they found the code without knowing the provenance, then they may not know that it is considered open to use, given the society in which we live.
Now I am not suggesting that you strap boilerplate to it, however a note that reassures people of their freedom to use the code without fear of reprisal is a polite consideration.
It is not because of wishing to be protected by the law, but rather trying to avoid being bashed over the head with it at some unspecified future time.
To expect complete strangers to trust that they understand your motives and opinions on the matter of whether they can use your work without worrying about it, would seem to be a stretch, at least in the general case unless it is made reasonably explicit, because a lot of the time society does not act that way and so it is useful to have some form of social signalling to let people know what the score is, which is all that licences are anyway, when you get right down to it.
And as far as trust goes, this is not a binary proposition, the middle ground is vast and has jungles in it.
>Now I am not suggesting that you strap boilerplate to it, however a note that reassures people of their freedom to use the code without fear of reprisal is a polite consideration.
I might do that. My other software comes with copyheart notices, I just hadn't gotten around to tacking it onto dali yet.... Originally dali is part of a now-on-ice project, which carried the notice.
Sorry by the way for nagging, is good of you in the first place to give stuff away for free without people like me then winging about the way you choose to do it. :)
This seems to be leveraging capabilities of modern browsers (hence the lack of dependencies) without any crufts, shims etc... for older browsers, which makes it very small. Compared to Raphael ( http://raphaeljs.com ) this seems to be much leaner. I took a rough scan of the features and they seem to be pretty comparable. But it would be interesting to see a few live demos to see whether they're just as smooth in the delivery.
The Clock demo is wrong. If you are going to already use the Swiss Railway face (The SBB will not be happy) you need to also have the second hand run continuously as well as have it stop at the top.
Mondaine used to make a watch that mimics the Swiss railway movement. Is was called stp2go, it looks like they just re-released it[0]. The old one had problems and would loose time quickly.
great timing. I'm in the process of creating an application displaying complex timelines with hundreds of elements, and EaselJS (or any canvas lib I suppose) is quite a handful.
it's not like canvas is slow (EaselJS' cache is a savior in this case). it's more like it hurts for me to even think of all the complex operations a canvas lib has to do to cope with various mouse interactions (calculating the objects under the mouse pointer), animation redrawing etc.
Out of interest, I'm considering porting an open source diagramming package that I wrote a while back (before canvas was widely supported) that although it was written mostly in JavaScript use a Flex component to actually render stuff and handle user input - given that EaselJS is pretty much a port of the Flex display object model to JS and canvas I thought it would be a good choice.
porting that would not be a problem, I'm quite sure.
but problems? yes. for example, the default EaselJS build strips out such DisplayObject methods that are not documented but are present in the unbuilt source code, e.g. getBounds(). I do understand there are reasons for it being undocumented, sure -- calculating bounds for a raster object may be very expensive on canvas, but since I'm working with strict square shapes, it works for me very well, hence I've got a custom EaselJS build to maintain.
I also had some problems with TweenJS (a tween co-lib for EaselJS) -- this was also solved by a custom build, as the downloaded minified version they're currently hosting was not up-to-date with EaselJS' newest changes (at least it wasn't couple of days ago).
that said, even though my code is not quite render-agnostic, I'll definitely try out Svgjs, as it's methods are almost one-on-one match to EaselJS'.
one problem with canvas is there are use cases where you are going to want to export as a vector graphics file. This is doable (but somewhat non-trivial) in an SVG element, but basically impossible for a canvas element.
actually, for example, EaselJS is written up very neatly and IS easy to work with, so I see absolutely no problem writing a custom adapter which would recursively reiterate the EaselJS Stage object (toString() method) and parse out all the shapes and what-not to whatever format you could possibly want.
sure, but with svg you already have that, written by the good folks at mozilla/google/apple.
I don't know how easelJS works, but the other really nice thing about svg is that modification of some attributes (color, stroke-width, etc.) is done using CSS, so if you, say, wanted to have the user be able to customize the interface in general cases (I was using this to annotate DNA which usually are done with arrows - one user might want genes in yellow and promoters in green, another vice versa, etc) that's a trivial implementation; no need to write a custom lookup table.
Nicely put! I wrote svg.js because I ran into limitations with Raphael. The great thing about Raphael is its compatibility with older browsers, but it is also its weakest spot because VML doesn't do everything SVG does, thereby limiting possibilities.
I wanted a library that still breathed SVG while providing a more unified API. I think too much abstraction leads to isolation. It's important to stay in touch with the underlying language, SVG.
downvoted by 4 points! my most ever! musta hit a nerve!
i'm sure this _looks_ like a non-informative post, at least
to some of you, so let me explain exactly why i made it...
mine was the first comment on this post, which languished
for an hour with nothing, and looked to be on its way to
being ignored totally, like the vast majority of posts...
i made a comment so people would come and look and maybe,
just maybe, add a more meaty one of their own. it worked.
i wanted the entry to get some attention, because i believe
s.v.g. is a highly underutilized format, and that has been
true for about a decade now, more or less, so even though
i don't have a lot to say about the topic, because i know
so little about it, i wanted to say "right on, thank you!".
which is exactly what "yay" meant...
could i have dressed it up with a little fat on the bones,
so it was more than just "yay"? yes, i could have. easily.
but at heart, it still woulda been nothing more than "yay".
so i decided to go with _the_plain_truth_of_the_matter_.
and if you want to down-vote that, then go ahead and do it.
i don't really give a dxmn. i don't have that much "karma",
and i don't intend to spend much time trying to procure it,
so your little brownie-points don't mean jxck-shxt to me...
(they certainly don't deserve any unadulterated profanity!)
this post got some attention, and i did my part to help it,
so i'm quite happy with what i did. and i'll do it again.
![http://www.3quarks.com/images/svg/station-clock.svg"](http://www.3quarks.com/images/svg/station-clock.svg"){kind=link}
While tools to dynamically generate SVG are needed sometimes the big future of SVG is artist-created images, so we generally in need of ways to manipulate , animate and add-to existing existing SVG images. SVG markup is already a better: clearer, faster, more embeddable way to create SVG images. Our tools should focus on adding value to the markup.
I use a lot of SVG these days and, sadly, SVG has to come with caveats. It currently performs terribly on iOS devices (especially large, detailed images) and there is no way to create progressively detailed svgs or mark areas for baking. Webkit did have an SVG scrolling bug where svgs were constantly repainted but, thankfully, that is fixed now.
Another gripe is SVG drawing tools. I am using a rather strange hodge-podge of a workflow (especially as I am a Mac user). Microsoft Expression Design → export as XAML → translate XAML to SVG.
It's actually quite effective / sensible for a few reasons 1) Expression Design is now a free download 2) XAML and SVG are very similar so the translation is reasonable straight-forward 3) Expression Design gives accurate pixel previews (and I have a second SVG testing tool that can flick between SVG and PNG to see where there are problems).
My tools are written in Go and may be of use / interest to other people. Let me know if you'd like to try them (caveat: they are one-user-one-developer-tools — me — so there is a layer of polish missing that I am happy to live with but you may not) and I'll work out how to upload them to GitHub.