Me and SVG(codepen.io)
codepen.io
Me and SVG
http://codepen.io/AmeliaBR/post/me-and-svg
230 comments
It really makes me sad to read the part about counting pennies and having to stretch such tiny advances while writing the books, especially when she describes her frustration at how much a framed copy that was sent by the publisher must have cost, compared to her frugal situation. It is a shame that writing down useful knowledge in a clear way is not better rewarded.
I wish more people on HN felt this way. I often see the opposite attitude expressed here towards writers: That it is not the audience's problem whether or not the writer eats. They should pick a different job if that sort of thing matters to them. (Granted, this is typically in discussions about online content, but I think it is kind of a class divide thing. Programmers seem to often not get how fortunate and well paid they really are.)
Guitar and video game players aren't well paid either. But they don't expect to be - they do it for fun.
Isn't that fair though? Writers could do it for fun and give away their work for free. Or they could get a job doing what the market wants and not enjoy it so much but get paid more. It's very much the same situation for programmers except programmers don't have the expectation that their work must be worth money just because they spent a lot of time on it. That's life for most people - our hobbies aren't usually worth as much money as our less enjoyable jobs.
Isn't that fair though? Writers could do it for fun and give away their work for free. Or they could get a job doing what the market wants and not enjoy it so much but get paid more. It's very much the same situation for programmers except programmers don't have the expectation that their work must be worth money just because they spent a lot of time on it. That's life for most people - our hobbies aren't usually worth as much money as our less enjoyable jobs.
"Isn't that fair though? Writers could do it for fun and give away their work for free."
No.
When I read this I think of Bruce Perens and BusyBox. [0] BusyBox, created by Perens as a floppy rescue/boot/installer disk for Debian, written as a single binary. [1],[2] Real handy if your partition failed or you needed to install an OS or update.
This didn't stop unscrupulous companies installing BusyBox charging for it and violating the GPL licensing agreements. [3] At no time did these companies chip in to help in the development of BB. Yet they wanted (needed) the inclusion of this useful software.
This is HN, a place where smart people hang out at the intersection of technology and commerce. I posted the article as an experiment to see what possible commercial possibilities could be imagined.
Reference
[0] https://en.wikipedia.org/wiki/BusyBox
[1] https://busybox.net/about.html
[2] https://busybox.net/oldnews.html
[3] https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits
No.
When I read this I think of Bruce Perens and BusyBox. [0] BusyBox, created by Perens as a floppy rescue/boot/installer disk for Debian, written as a single binary. [1],[2] Real handy if your partition failed or you needed to install an OS or update.
This didn't stop unscrupulous companies installing BusyBox charging for it and violating the GPL licensing agreements. [3] At no time did these companies chip in to help in the development of BB. Yet they wanted (needed) the inclusion of this useful software.
This is HN, a place where smart people hang out at the intersection of technology and commerce. I posted the article as an experiment to see what possible commercial possibilities could be imagined.
SVG is too important to the web
to let it whither and die.
Reference
[0] https://en.wikipedia.org/wiki/BusyBox
[1] https://busybox.net/about.html
[2] https://busybox.net/oldnews.html
[3] https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits
I don't see what this has to do with the argument that "Writers could do it for fun and give away their work for free."
You can argue the point 2 ways
1. Bruce Perens did BusyBox for fun and gave it away for free. After words some people were bad and got sued. So what does his making it for fun and free have to do with after words people got sued
2. Bruce Perens did Busybox and fun and gave it away not for free. His price is that if you it in a product (or portions of it, details don't matter to the point) that product (or portions of it) must also be GPLed.
If you take this interpretation then we're back to the same thing, what does this story have to do with "Writers could do it for fun and give away their work for free."
You can argue the point 2 ways
1. Bruce Perens did BusyBox for fun and gave it away for free. After words some people were bad and got sued. So what does his making it for fun and free have to do with after words people got sued
2. Bruce Perens did Busybox and fun and gave it away not for free. His price is that if you it in a product (or portions of it, details don't matter to the point) that product (or portions of it) must also be GPLed.
If you take this interpretation then we're back to the same thing, what does this story have to do with "Writers could do it for fun and give away their work for free."
> If you take this interpretation then we're back to the same thing, what does this story have to do with "Writers could do it for fun and give away their work for free."
Why should writers be relegated to only ever being allowed to "do it for fun" while programmers are not?
Why should writers be relegated to only ever being allowed to "do it for fun" while programmers are not?
I mean, that depends on what you are writing and programming.
If I want someone to pay me for programming, I have to write something they want. The same is true for writers.
The point the original post was making is that if not enough people want what you are writing (code or text), you can do it for fun and give it away free. You can't expect to get paid for doing something you love. It's amazing if you can, and I'm incredibly lucky that I do, but it's not something I expect.
Hopefully in the future with enough automation people can just do things for fun, and all the jobs we need can be automated. We aren't there yet - but most people can work a job and have time for hobbies in modern developed countries.
Now, arguably, there is a lot of value in this work and we should be supporting it. That may be true, but that is a separate problem. The solution to this may be getting enough people to take note and care, and this post might be a start on that.
If I want someone to pay me for programming, I have to write something they want. The same is true for writers.
The point the original post was making is that if not enough people want what you are writing (code or text), you can do it for fun and give it away free. You can't expect to get paid for doing something you love. It's amazing if you can, and I'm incredibly lucky that I do, but it's not something I expect.
Hopefully in the future with enough automation people can just do things for fun, and all the jobs we need can be automated. We aren't there yet - but most people can work a job and have time for hobbies in modern developed countries.
Now, arguably, there is a lot of value in this work and we should be supporting it. That may be true, but that is a separate problem. The solution to this may be getting enough people to take note and care, and this post might be a start on that.
> If I want someone to pay me for programming, I have to write something they want. The same is true for writers.
Yes, although the argument in this particular thread is that writing is ~broadly~ underrewarded and that is OK because markets. Attempting to influence a market to reward people better is considered to be a bad thing - the only way people should be able to do that is by not participating in the market, according to many. Unless it's to do with programming. But not game development.
Yes, although the argument in this particular thread is that writing is ~broadly~ underrewarded and that is OK because markets. Attempting to influence a market to reward people better is considered to be a bad thing - the only way people should be able to do that is by not participating in the market, according to many. Unless it's to do with programming. But not game development.
"Selling used bubblegum also suffers from being underrewarded. I spent all this time chewing gum and nobody wants to buy it? How's that fair for me? I chewed the gum - I deserve to be paid!"
Just because you do something (regardless of the value of doing that thing) doesn't mean you deserve to be paid for doing that thing. Especially if nobody is interested in paying you to do that thing.
So yes. It is "OK because markets". If you expect to be rewarded for your writing, make sure there is a marketable interest in what you will be writing. You may have to make an MVP (maybe the first and second chapters) to test the waters, but that isn't different from a programmer needing to make an MVP to test the waters for their potential product.
Just because you do something (regardless of the value of doing that thing) doesn't mean you deserve to be paid for doing that thing. Especially if nobody is interested in paying you to do that thing.
So yes. It is "OK because markets". If you expect to be rewarded for your writing, make sure there is a marketable interest in what you will be writing. You may have to make an MVP (maybe the first and second chapters) to test the waters, but that isn't different from a programmer needing to make an MVP to test the waters for their potential product.
The issue is that the exact same communities which decry writers for asking that they get paid what they think they're worth, will cry that the entire software development market outside the SV bubble is "unfair" to developers because it's not paying SV market prices.
They also cry about immigrants taking their jobs at lower rates, outsourcing, people choosing to hire the new grad instead of the expert, and plenty of other things that could be responded to with "it's OK because markets".
They also cry about immigrants taking their jobs at lower rates, outsourcing, people choosing to hire the new grad instead of the expert, and plenty of other things that could be responded to with "it's OK because markets".
"I don't see what this has to do with the argument ... If you take this interpretation then we're back to the same thing, what does this story ..."
Complains a lot.
Complains a lot.
This doesn't seem like a failure to dream up a way to compensate software authors, this seems like simple copyright infringement/theft.
Well firstly, most of the best writing isn't produced by people that are having fun the whole time. Most of it is the result of authors showing up to work, day after day, whether they felt like it or not.
Secondly, authors aren't the only people behind a good book. As evidenced by the typical "Acknowledgements" section, there's also the reviewers, editors, typesetters, artists, as well as long-suffering spouses and kids.
But crucially, people produce their best work under some kind of coach; and coaching is not generally fun. So coaches need to be paid, which means that performers need to be paid.
Secondly, authors aren't the only people behind a good book. As evidenced by the typical "Acknowledgements" section, there's also the reviewers, editors, typesetters, artists, as well as long-suffering spouses and kids.
But crucially, people produce their best work under some kind of coach; and coaching is not generally fun. So coaches need to be paid, which means that performers need to be paid.
Yes, that's all true. But I'm talking about the case where authors aren't making much money compared to the effort they put in. What if the end product is so unuseful or so interchangable with thousands of similar free products that nobody wants to pay for it? In that case, I think it's wrong to ask somebody to give money to such an author. They're generating a product that costs more to produce than what it's worth.
Some musicians hire expensive guitar coaches, have help from friends, hire producers to record their music and in the end they're made something that nobody wants badly enough to pay for, so it's an overall loss. I'm talking about these cases. Why should we insist that somebody pay them for their time rather than how desirable their product is?
Some musicians hire expensive guitar coaches, have help from friends, hire producers to record their music and in the end they're made something that nobody wants badly enough to pay for, so it's an overall loss. I'm talking about these cases. Why should we insist that somebody pay them for their time rather than how desirable their product is?
its simply lazy thinking to assume that people are paid what they deserve. not that your point isnt generally fair, but i always feel like we go too far in the direction of assuming people are paid what they deserve.
Why has every response to my comment misinterpreted it? Do you all have an axe to grind against someone and you thought I was that someone?
I'm simply saying that many writers produce work with very little value to other people, and that those writers shouldn't expect to be paid for their "work". Nobody pays me to eat food, even though I enjoy doing that.
I'm simply saying that many writers produce work with very little value to other people, and that those writers shouldn't expect to be paid for their "work". Nobody pays me to eat food, even though I enjoy doing that.
How is going to school, starting up a career and writing books is any different than going to school, starting up a career and writing code?
Do you think that the code we write add that much value to society? Unless you are a computer scientist and pushing the boundaries, our code will simply rot away in 4 years and nobody will remember one line of it.
Do you think that the code we write add that much value to society? Unless you are a computer scientist and pushing the boundaries, our code will simply rot away in 4 years and nobody will remember one line of it.
The equivalent in writing for what most programmers do would be marketing, PR, journalism, or technical writing. You can get a paying job to write, it's just going to be that kind of writing - not for your Next Great American Novel. Likewise, I get paid a salary to bolt together shitty enterprise software and automate call-center workers out of jobs - not to tickle my fancy writing video games or exploring the corners of computer science.
Aren't we talking about technical writing? The problem in the OP's post are about writing a book on SVG.
I would be more likely to agree if this thread was about the issues encountered while writing a children's story book.
I would be more likely to agree if this thread was about the issues encountered while writing a children's story book.
Writing a technical book is, as far as I was aware, well known to be a losing bet, where it's exceedingly rare that authors make back their advances. e.g. http://www.voidspace.org.uk/python/articles/technical-writin...
Who needs a book about SVG? When I needed to build charts I took couple tutorials plus searched answers on stack overflow. It's way more efficient than reading huge book.
So, such books are needed by very small group of people. And this defines the pay.
So, such books are needed by very small group of people. And this defines the pay.
> Who needs a book about SVG? When I needed to build charts I took couple tutorials plus searched answers on stack overflow.
The people out there who pride themselves into being able to do their work without relying on googling everything? What if you have an idea or a requirement that has never been done before?
The people out there who pride themselves into being able to do their work without relying on googling everything? What if you have an idea or a requirement that has never been done before?
How does what people deserve have anything to do with it?
A programmer might provide $100,000 of value to a company over a year, but that doesn't mean they deserve that much, or even any given fraction of that much. People are and should be paid exactly what they can get for their work. Selling things itself is work.
A programmer might provide $100,000 of value to a company over a year, but that doesn't mean they deserve that much, or even any given fraction of that much. People are and should be paid exactly what they can get for their work. Selling things itself is work.
"People are and should be paid exactly what they can get for their work" what? to see how this thinking makes no sense, ask yourself- chronologically, when did this become true? was it after the great depression? was it during communist china? was it before we had fiat currency and had to barter? did it happen some time recently? why? people have been paid vastly differently, including not at all, for the same work. or maybe you have a pure, survival of the fittest mentality (for lack of a better phrase), and think it has it always been true? if always... then how do you feel if stealing gets you paid more? what if lying gets you paid more? what if fucking over other people gets you paid more? having slaves was incredibly profitable. you shouldn't be paid more for that, right?
What about things that are for the public good but doesn't have an immediate market demand, like government-funded research grants for scientists? The market is only concerned with short-term profits, it's not the optimal allocation of resources like some would have you believe. Projects that contribute to the commons should be funded, as long as the necessary check and balances are in place.
What if you can't get a job doing what the market wants?
Then you're disabled and social welfare will support you. Same as anyone else who can't get a job.
are you by any chance not in the U.S?
http://work.chron.com/salaries-pro-gamers-26166.html
http://www.simplyhired.com/salaries-k-guitar-player-jobs.htm...
http://www.simplyhired.com/salaries-k-guitar-player-jobs.htm...
You know these aren't representative at all. Almost every video gamer and guitar player earns nothing for their activities. Those millions of 0's won't be included in the guitar player salary graph.
Yes, I am aware of that. But you are just confirming my original observation here. You are acting like writers have no right to earn a decent living. Just because people might enjoy their work does not mean they should starve or be required to get some other job they don't enjoy to pay the bills. I get tired of that insinuation.
There are programmers who enjoy their work. They don't get told they have no right to the high salaries typical of programmers because they aren't suffering enough.
There are programmers who enjoy their work. They don't get told they have no right to the high salaries typical of programmers because they aren't suffering enough.
You're talking to the wrong person. I entirely agree with J. K. Rowling's right to earn millions from her writing. Because that's what people were willing to pay her for it. How else can we decide how to take money from one person and give it to another besides the market? Who do you want to pay that money? The taxpayer? Are you wanting free income for every author, artist, game player or hobbiest so they don't have to suffer unpleasant work? That might well be a valid idea but it's quite different from what you said. How do you "earn" a living when you're supported by charity?
Edit: What are you proposing instead of the current market situation? Do you want publishers to do something different? Governments? GoogFaceAzons? Readers? The general populace?
Edit: What are you proposing instead of the current market situation? Do you want publishers to do something different? Governments? GoogFaceAzons? Readers? The general populace?
These comments usually occur in discussions about online ads. That isn't charity. Your assertion that it is charity is ridiculous.
[deleted]
do drug smugglers deserve millions?
do cheating athletes who aren't caught deserve millions?
do patent trolls deserve millions?
do televangelists deserve millions?
do oil and mining companies that destroy the environment deserve millions?
do cheating athletes who aren't caught deserve millions?
do patent trolls deserve millions?
do televangelists deserve millions?
do oil and mining companies that destroy the environment deserve millions?
These are different problems. We're talking about authors and artists here. How and why should authors be paid for producing work that nobody wants? Should somebody else pay authors to pursue their hobby even when it doesn't provide much value to others?
i agree its hard to know what to pay. but i think you would rather have a contented artist producing work that you were indifferent to, than a highly paid patent troll, right?
> You are acting like writers have no right to earn a decent living
Correct.
Writers, programmers, football players all do not have a _right_ to earn money.
Instead, _people_ have a right to get a job to earn themselves a decent income to make a good living. If I choose to do something that doesn't result in a good enough income, then that's on me.
Correct.
Writers, programmers, football players all do not have a _right_ to earn money.
Instead, _people_ have a right to get a job to earn themselves a decent income to make a good living. If I choose to do something that doesn't result in a good enough income, then that's on me.
I tend to agree; the "right to earn a decent living" is inherently incompatible with market economy. On the market, you only have the right to accept or refuse a transaction.
On the other hand, I also believe everyone should have a right to decent life - that's why I'm for extensive social security, and would happily support basic income if someone figures out how to do it right.
I feel like people are sometimes using "right to earn a decent living" as a proxy for "right to have a decent life" in order to imply that they want to have people working for living. But I think those concepts need to be clearly separated, because the concept of "right to earn a decent living" directly interferes with self-regulatory capabilities of the market, which is why we want free markets in the first place.
On the other hand, I also believe everyone should have a right to decent life - that's why I'm for extensive social security, and would happily support basic income if someone figures out how to do it right.
I feel like people are sometimes using "right to earn a decent living" as a proxy for "right to have a decent life" in order to imply that they want to have people working for living. But I think those concepts need to be clearly separated, because the concept of "right to earn a decent living" directly interferes with self-regulatory capabilities of the market, which is why we want free markets in the first place.
I went into programming because I saw how well paid a profession it would be. I could have done art or linguistics or something else. I enjoy it too, but I don't expect to be paid well for making videogames so I also do work I enjoy less that pays better.
I agree with you that writers of valuable content should be compensated better, but I don't understand this attitude that one should be able to go into any job you want and expect to make a living. If you write something that people want, don't give it to them until they pay for it.
Did the publisher in Amelia's case just screw her in negotiations, or do they always underpay their writers and backload it to royalties?
I agree with you that writers of valuable content should be compensated better, but I don't understand this attitude that one should be able to go into any job you want and expect to make a living. If you write something that people want, don't give it to them until they pay for it.
Did the publisher in Amelia's case just screw her in negotiations, or do they always underpay their writers and backload it to royalties?
"Did the publisher in Amelia's case just screw her in negotiations,"
I suppose people were just not interested in SVG so much, so not much sold books -> not much money.
I suppose people were just not interested in SVG so much, so not much sold books -> not much money.
This problem has not been fixed ever - Robert Frost - legendary American poet - worked at a bank while he was famous.
So... IDK. I think people just roll with it and hope it'll all click at the end.
So... IDK. I think people just roll with it and hope it'll all click at the end.
Writers in the film and television industry fixed it, by unionizing.
But they don't get to put their name on the cover.
My company (scripted.com) is looking to add more proven experts to our writer marketplace. We would be more than happy to fast-track the author of this piece through our writer application process, as she clearly has unique domain expertise. Our freelancers work all over the world, and tech writing is in very high demand. No promises but I might be able to convince our marketing department to become her first customer. Our blog could use content discussing the state of digital publishing technologies.
[email protected]
[email protected]
I thought this was sad as well, especially since there are many people who make a lot more than this with self-published technical books.
If I'm completely honest, I hadn't heard of the author before reading her post, even though I try to keep up with the web development scene. This leads me to think that maybe she would've benefited from putting her name out there more, something many of us are hesitant to do.
If I'm completely honest, I hadn't heard of the author before reading her post, even though I try to keep up with the web development scene. This leads me to think that maybe she would've benefited from putting her name out there more, something many of us are hesitant to do.
I've been lurking in the www-svg mailing list for years now (originally subscribed to bring up an issue with rendering I observed). Amelia more or less suddenly appeared in the discussions a while ago, but it was definitely noticeable. Heck, it's hard to miss her name at least at the point where SVG is (was?) standardised.
I do believe, however, that many, many people who use web technologies, never bothered to look up the actual specification, nor are they involved or watching the standardisation process. So it's easy to miss names that only crop up in that area.
I do believe, however, that many, many people who use web technologies, never bothered to look up the actual specification, nor are they involved or watching the standardisation process. So it's easy to miss names that only crop up in that area.
2¢ — As someone who is actively working with SVG (at the level of DOM APIs, not just using SVG icon packs), I've found her name and work to be brought up quite often. Discussions of the SVG spec generally mention her in some capacity. I've seen her cited in countless blog posts, and guest on a few podcasts. In my experience she's been as visible as anyone active in the SVG space (like, say, Sara Soueidan or Sarah Drasner).
They need to unionize. Writers in Hollywood get paid really well, because they have a union: The Screen Writers Guild.
They also get paid really well because Hollywood makes a lot of money and the national labour board ruled that most of the production companies in Hollywood HAVE to use that guild.
It's not clear to me who this technical writers union would be negotiating with, or why they'd have leverage over that entity. O'Reilly obviously has a limited pool of people it can find to write a book about SVG, but that also implies those people should have leverage to command more than a $4000 advance without needing to unionize.
It's not clear to me who this technical writers union would be negotiating with, or why they'd have leverage over that entity. O'Reilly obviously has a limited pool of people it can find to write a book about SVG, but that also implies those people should have leverage to command more than a $4000 advance without needing to unionize.
The tech industry has a lot of money. Probably more than Hollywood, if you define "tech" broadly. Hypothetically, if all the technical book authors, how-to bloggers, and Stack Overflow contributors were to go on strike, they would have considerable leverage over various wealthy software firms.
They'd also have to somehow remove all the old how-to content from the internet and somehow find a way to stop scabs. Any up and coming developer anywhere in the world could find the basic specs and references needed to become a "strikebreaker" expert on a given topic.
The nature of our industry and the widely disseminated information makes me really skeptical that could ever happen, even if there was a strong will to do so amongst developers and technical writers.
The nature of our industry and the widely disseminated information makes me really skeptical that could ever happen, even if there was a strong will to do so amongst developers and technical writers.
I'm not saying it's that likely to happen, I'm just pointing out that all this "oh well, technical writing is just low-paid worthless work and always has to be" fatalism is misguided.
There are proven models for demanding higher pay for writing, but they require labor solidarity (and some measure of accountability from industry)
There are proven models for demanding higher pay for writing, but they require labor solidarity (and some measure of accountability from industry)
I suspect many books just wouldn't get written if advances had to be higher, there isn't a huge amount of money sloshing about in technical publishing.
I want to be a journalist=>
I can't travel =>
graphics can be my niche =>
SVG is interesting =>
this competition is for me =>
I fail stupidly =>
I blog and show my stuff =>
This book needs serious help, I am not counting my time =>
Oh oh, i am a published author, this is weird =>
I worked so hard, 5 books! =>
Expert on W3C commitee =>
Seriously, I am THE freaking expert in this field!!=>
More hard work, a lot =>
Oh shit, people are not interested in this stuff anymore =>
What am I doing with my life????
This is a beautiful story. Thanks for sharing so well.
This is a beautiful story. Thanks for sharing so well.
The whole story could have a way better outcome if you replace SVG with an area of expertise that helps companies create value :/
I feel like SVG is currently more important than ever - it's a much easier solution to the problem of display density which is currently rearing its head again in light of phones and other high-density displays.
SVG does create lots of value. Google uses it a lot in the Docs suite, in slides for example.
It bums me out to hear SVG is in such limbo, I've been looking forward to SVG 1.2 support. It seems to be taking a long time, I guess this is why.
It's strange because I know many many companies are using SVG at least a bit for their sites. Maybe it's simmering just under the threshold where it seems necessary to have to do business, but so many sites would be hosed if SVG suddenly went away.
Is part of the problem authoring tools? Every time I need to make some SVG by hand, I look around and keep coming back to Inkscape and Illustrator. I can't afford Illustrator, and Inkscape has just never stuck for me, it feels very clunky. I've used lots of the other tools out there but nothing seems great.
It's strange because I know many many companies are using SVG at least a bit for their sites. Maybe it's simmering just under the threshold where it seems necessary to have to do business, but so many sites would be hosed if SVG suddenly went away.
Is part of the problem authoring tools? Every time I need to make some SVG by hand, I look around and keep coming back to Inkscape and Illustrator. I can't afford Illustrator, and Inkscape has just never stuck for me, it feels very clunky. I've used lots of the other tools out there but nothing seems great.
> Is part of the problem authoring tools? Every time I need to make some SVG by hand, I look around and keep coming back to Inkscape and Illustrator. I can't afford Illustrator, and Inkscape has just never stuck for me, it feels very clunky. I've used lots of the other tools out there but nothing seems great.
I totally get this. I don't have Illustrator, but occasionally I get Illustrator produced SVGs and they remind me of HTML produced by early 2000 Word.
And I hate Inkscape with a passion, mostly the UI. I like exact coordinates for doing technical diagrams, and Inkscape seems to make that really hard. I have no issues with UIs that have a learning curve, and have previously gotten used to InDesign and Blender fine. But it seems like I'm fighting Inkscape all the way, only to have the output be of low quality.
What I actually use now is TikZ in LaTeX + dvisvgm, which I then pipe through SVGO. Super happy with the results, although writing TikZ isn't exactly smooth either. And LaTeX is a whole different world of pain and annoyance, so using it for just SVG seems wrong. But TikZ/PGF is pretty mature, and dvisvgm has a great, clean code base.
I totally get this. I don't have Illustrator, but occasionally I get Illustrator produced SVGs and they remind me of HTML produced by early 2000 Word.
And I hate Inkscape with a passion, mostly the UI. I like exact coordinates for doing technical diagrams, and Inkscape seems to make that really hard. I have no issues with UIs that have a learning curve, and have previously gotten used to InDesign and Blender fine. But it seems like I'm fighting Inkscape all the way, only to have the output be of low quality.
What I actually use now is TikZ in LaTeX + dvisvgm, which I then pipe through SVGO. Super happy with the results, although writing TikZ isn't exactly smooth either. And LaTeX is a whole different world of pain and annoyance, so using it for just SVG seems wrong. But TikZ/PGF is pretty mature, and dvisvgm has a great, clean code base.
I started out doing vector based illustration in Illustrator and have been using Inkscape for probably 16 years now. I really like Inkscape for the performance and simplicity of it. It's also got a bunch of features I've come to enjoy, like specifying exact positions for guides, and guides on angles. The menus and tool pallets kind of suck, but I don't use those anyway. Really from what I've seen in the industry, most designers are heavy keyboard users and aren't clicking around on menus to do stuff. It takes too long!
The only big drawback for me is that it doesn't support CMYK color, so when I need something printed I bring it in to Illustrator and make sure my colors are mapped to the appropriate CMYK colors.
The only big drawback for me is that it doesn't support CMYK color, so when I need something printed I bring it in to Illustrator and make sure my colors are mapped to the appropriate CMYK colors.
> The only big drawback for me is that it doesn't support CMYK color
This has been painful for me. As a side project I made a card game and produced the cards in SVG as a template (handwritten, but I use Inkscape to convert to PDF/PNG, so Inkscape has to render it correctly), a CSV file for all text content that should appear in it, and some scripting. SVG has been awesome for that, as it's a vector graphics format that's very easy to programmatically modify.
But when it comes to printing things you suddenly find yourself in a world where RGB is downright painful. Slightly off colours, wrong black tones (RGB black is blacker than CMYK black, so it's always mixed with colours). It probably wouldn't matter much with photos, but text and shapes are very affected.
So in the end we had to take Illustrator to the final PDF, convert to CMYK, and make sure every last bit of black is CMYK(0,0,0,1). SVG as a web technology only caters to sRGB as a colour space; there have been attempts at standardising CMYK, and Batik had a half-finished implementation, I think. But eventually both the standardisation efforts and the implementation were pulled, IIRC.
This has been painful for me. As a side project I made a card game and produced the cards in SVG as a template (handwritten, but I use Inkscape to convert to PDF/PNG, so Inkscape has to render it correctly), a CSV file for all text content that should appear in it, and some scripting. SVG has been awesome for that, as it's a vector graphics format that's very easy to programmatically modify.
But when it comes to printing things you suddenly find yourself in a world where RGB is downright painful. Slightly off colours, wrong black tones (RGB black is blacker than CMYK black, so it's always mixed with colours). It probably wouldn't matter much with photos, but text and shapes are very affected.
So in the end we had to take Illustrator to the final PDF, convert to CMYK, and make sure every last bit of black is CMYK(0,0,0,1). SVG as a web technology only caters to sRGB as a colour space; there have been attempts at standardising CMYK, and Batik had a half-finished implementation, I think. But eventually both the standardisation efforts and the implementation were pulled, IIRC.
I had similar frustrations with Inkscape's UI, even after years of using it. I've been happy with Affinity Designer [0] (Windows version) as a replacement that doesn't require a monthly subscription.
[0] https://affinity.serif.com/en-us/designer/
[0] https://affinity.serif.com/en-us/designer/
This looks really good, thanks! Nice support for isometry.
CorelDraw is really nice for vector editing. The included PhotoPaint has languished on the vine but its unique object interface makes many things that are obtuse in PS or Gimp easy to handle.
That being said it's hard to beat Inkscape's native SVG support. You don't get surprised by fills and filters bloated into bitmaps like the legacy tools are wont to do.
That being said it's hard to beat Inkscape's native SVG support. You don't get surprised by fills and filters bloated into bitmaps like the legacy tools are wont to do.
While inkscape is fairly terrible at exact work, you can do it by using the builtin xml editor. I designed a fully working planetary gear train for a clock in inkscape. It involves placing mostly rectangles exactly using the XML editor and then using the snapping tools to place other objects relative to these exact positions. place rectangle -> control-shift -> change x and y properties.
> I can't afford Illustrator, and Inkscape has just never stuck for me, it feels very clunky. I've used lots of the other tools out there but nothing seems great.
Have you tried Affinity Designer? I'm not a designer, but for me it's simply amazing. And it's only $50, no subscription bullshit.
Have you tried Affinity Designer? I'm not a designer, but for me it's simply amazing. And it's only $50, no subscription bullshit.
They seem to have an incredibly effective marketing strategy. The launch trailers for both of their flagship graphics editors were super sexy.
But are all the features really there?
I watched a few videos of people using it about half a year ago and I noticed that a) a few essential features were missing and b) the interfaces have limited room for customization, and they are split up across several "workflow" views that really just get in the way.
Does that mirror your own experience? Have you used other vector drawing programs like Inkscape, Illustrator, or Blender?
But are all the features really there?
I watched a few videos of people using it about half a year ago and I noticed that a) a few essential features were missing and b) the interfaces have limited room for customization, and they are split up across several "workflow" views that really just get in the way.
Does that mirror your own experience? Have you used other vector drawing programs like Inkscape, Illustrator, or Blender?
> Does that mirror your own experience? Have you used other vector drawing programs like Inkscape, Illustrator, or Blender?
My experience with creative tools such as this is very limited. I mostly customize things and follow instructions from video tutorials. That said, I can't stand Inkscape on macOS. It's a disaster, and not worth the trouble.
I've used Illustrator during their 30 day trial, but since I'm not using it on a daily basis, it's not worth the subscription.
My experience with creative tools such as this is very limited. I mostly customize things and follow instructions from video tutorials. That said, I can't stand Inkscape on macOS. It's a disaster, and not worth the trouble.
I've used Illustrator during their 30 day trial, but since I'm not using it on a daily basis, it's not worth the subscription.
Affinity hands-down has the most attractive pricing scheme I've seen for its class of software. I have no doubt it isn't worth every penny. I prefer supporting Free Software like GIMP and Inkscape when possible, but there are some things that Photoshop does much better, and some of these things were absent in my evaluation of Affinity Photo.
The only software I've found to have a better pricing overall scheme is the Substance suite. $20 a month rent-to-own, and you can "buy" individual programs from the suite with this strategy one at a time instead of all at once, in case you want to secure ownership of a particular program. It's an incredible business model for software.
The only software I've found to have a better pricing overall scheme is the Substance suite. $20 a month rent-to-own, and you can "buy" individual programs from the suite with this strategy one at a time instead of all at once, in case you want to secure ownership of a particular program. It's an incredible business model for software.
I prepare files for my laser cutter, I used to use Illustrator but the subscription fees were just ridiculous. When Affinity Designer came out I bought it and started using that instead.
It definitely doesn't have feature parity with Illustrator and while quite polished feels like a beta to me because of some interface issues. The one that always bugs me is that it's really painful to delete a segment between two points (ie. for vector A-B-C-D I want to remove B-C and end up with two vectors A-B and C-D).
I have an illustrator friend who uses Affinity and he loves it because he doesn't have the same precision requirements I do (every extra line in a laser design is wasted time on the cutter). So it depends what you're doing with it.
Affinity is committed to continuing development on it and those updates are free, and adoption has been quite good so I expect issues like this to be fixed eventually.
It definitely doesn't have feature parity with Illustrator and while quite polished feels like a beta to me because of some interface issues. The one that always bugs me is that it's really painful to delete a segment between two points (ie. for vector A-B-C-D I want to remove B-C and end up with two vectors A-B and C-D).
I have an illustrator friend who uses Affinity and he loves it because he doesn't have the same precision requirements I do (every extra line in a laser design is wasted time on the cutter). So it depends what you're doing with it.
Affinity is committed to continuing development on it and those updates are free, and adoption has been quite good so I expect issues like this to be fixed eventually.
I've used Illustrator and Inkscape, but Affinity Designer is my daily go-to. There's certainly some stuff it doesn't have that I miss, but overall it's a great piece of software, with fantastic performance and enough novel, useful features that it's definitely worth the price, and using over the other two.
You should try Sketch out. I also despise making SVGs in Illustrator. I find it much, much easier in Sketch.
For me who is comfortable in inkscape or illustrator my issue has been a library thing when it comes to using SVG. You end up having to try and strip out half the rendering engine of something way too big (Skia, Cairo) for your one off thing and it just ends up dominating the complexity of the project in the early stages.
It feels that there isn't a really great SVG library to build consensus around compared to a lot of other things that people can hack on.
It feels that there isn't a really great SVG library to build consensus around compared to a lot of other things that people can hack on.
> Is part of the problem authoring tools? Every time I need to make some SVG by hand
I find it strange how unfriendly or unintuitive it is to do by hand. I'd like to use it for more programmatic stuff, but it feels like more of an interchange format than something most of us should understand.
I find it strange how unfriendly or unintuitive it is to do by hand. I'd like to use it for more programmatic stuff, but it feels like more of an interchange format than something most of us should understand.
That may be one of the problems with SVG 2. SVG in its full capacity seems rarely used on the web.¹
SVG as a static vector image format, or as an export target for other tools, or as a vector image format easily scripted on the web ... all those things seem to be met already by what is implemented in browsers. What is missing have been mostly things that can be emulated with a bit more work (e.g. markers were problematic in some implementations for a while). SVG 2 brings a lot more things that make it easier for people to author SVG by hand (new path commands), as well as some features that have been simply impossible to do before (gradient meshes). But those need to be implemented, of course, and since SVG seems to be doing well enough currently, it looks like no more effort is warranted (and it seems to be hard to market it as well as new JS features). From the outside as a user of SVG it looks like all major browser vendors have given up improving their SVG support, since it's almost complete in all of them and there's mostly feature parity between them.
In a way the same happens to the canvas 2D context, but admittedly, there's little to improve or change in an immediate-mode raster graphics API since those have been mostly the same since at least the 80s, so I guess there isn't a newer specification to implement in contrast to SVG.
____________
¹ At work we still regularly stumble over things browser vendors broke in their latest update when it comes to SVG (we use it to build an interactive graph editing component) that apparently weren't noticed when testing on the top 1000 sites or so. It can be frustrating.
SVG as a static vector image format, or as an export target for other tools, or as a vector image format easily scripted on the web ... all those things seem to be met already by what is implemented in browsers. What is missing have been mostly things that can be emulated with a bit more work (e.g. markers were problematic in some implementations for a while). SVG 2 brings a lot more things that make it easier for people to author SVG by hand (new path commands), as well as some features that have been simply impossible to do before (gradient meshes). But those need to be implemented, of course, and since SVG seems to be doing well enough currently, it looks like no more effort is warranted (and it seems to be hard to market it as well as new JS features). From the outside as a user of SVG it looks like all major browser vendors have given up improving their SVG support, since it's almost complete in all of them and there's mostly feature parity between them.
In a way the same happens to the canvas 2D context, but admittedly, there's little to improve or change in an immediate-mode raster graphics API since those have been mostly the same since at least the 80s, so I guess there isn't a newer specification to implement in contrast to SVG.
____________
¹ At work we still regularly stumble over things browser vendors broke in their latest update when it comes to SVG (we use it to build an interactive graph editing component) that apparently weren't noticed when testing on the top 1000 sites or so. It can be frustrating.
if you use Mac OS or Windows, check out Affinity Designer. Its a very polished vector drawing program as powerful as Adobe Illustrator but only $50 and it included some image editing tools. it works with SVG, PDF, and other format. It pairs well with Affinity Photo which gives Photoshop a run for its money (and is also $50)
I think we (the web) chronically underestimate the importance of SVG. I mean we all use pixel graphics (JPG, PNG, GIF) every day, build services to scale images and have multiple formats for them have to admit, that they are not 100% perfect most of the time.
SVG, on the other hand, doesn't need 5 different versions of the same image just to look okay on the receiving display. Even more, it always has 100% quality on the receiving device. As far as I am concerned, there are only two main problems with SVG:
1. The creation is painful
2. The renderer compatibility is too weak.
While creation problem has many layers, I think one thing that could be improved is Inkscape usability. I spend the last months every now and then to learn to handle Inkscape and the first steps were so painful (and I knew what SVG is and was quite able to handle Gimp). I am sure if some usability experts would be involved in its development, many things would be implemented differently. And I really hope, someone will change that as Inkscape is such a powerful tool which should be quite accessible to the majority of users.
Regarding the render compatibility, I think it is very important to fix that in the near future. I have high hopes that SVG2 will help here, but I think it is also our job as the web community to show the browser vendors, that we want that fixed version of SVG.
SVG, on the other hand, doesn't need 5 different versions of the same image just to look okay on the receiving display. Even more, it always has 100% quality on the receiving device. As far as I am concerned, there are only two main problems with SVG:
1. The creation is painful
2. The renderer compatibility is too weak.
While creation problem has many layers, I think one thing that could be improved is Inkscape usability. I spend the last months every now and then to learn to handle Inkscape and the first steps were so painful (and I knew what SVG is and was quite able to handle Gimp). I am sure if some usability experts would be involved in its development, many things would be implemented differently. And I really hope, someone will change that as Inkscape is such a powerful tool which should be quite accessible to the majority of users.
Regarding the render compatibility, I think it is very important to fix that in the near future. I have high hopes that SVG2 will help here, but I think it is also our job as the web community to show the browser vendors, that we want that fixed version of SVG.
It's funny that some people say that about Inkscape usability. As a quite graphically-challenged person, it's the only graphics program I have been able to learn to an acceptable degree, and in an acceptable amount of time. Fireworks, Corel Draw, GIMP, etc. look like impregnable fortresses for me and I always end up using Inkscape.
Maybe people like me who are just bad at graphics have different needs. Something like visual basic vs. real programming languages, I guess?
Maybe people like me who are just bad at graphics have different needs. Something like visual basic vs. real programming languages, I guess?
> As a quite graphically-challenged person, it's the only graphics program I have been able to learn to an acceptable degree
As somebody who spends most of his workday in graphics software, inkscape is a nightmare for me to use. And I think a lot of that is because it rejects a lot of the pseudo-conventions enshrined in other graphics software that I have burned into my muscle memory (shift to lock aspect ratio when scaling, control-plus to zoom, double-click to enter a group, etc etc etc).
As somebody who spends most of his workday in graphics software, inkscape is a nightmare for me to use. And I think a lot of that is because it rejects a lot of the pseudo-conventions enshrined in other graphics software that I have burned into my muscle memory (shift to lock aspect ratio when scaling, control-plus to zoom, double-click to enter a group, etc etc etc).
Have you tried Sketch?
I agree, all the tools you listed have serious usability problems for the lay user, especially when it comes to an SVG workflow. But in my experience, Inkscape has many of those same problems. Sketch is the only graphics editor I've used that I feel like I don't have to fight with all the time.
I agree, all the tools you listed have serious usability problems for the lay user, especially when it comes to an SVG workflow. But in my experience, Inkscape has many of those same problems. Sketch is the only graphics editor I've used that I feel like I don't have to fight with all the time.
> it always has 100% quality on the receiving device
It doesn't actually, but it's close.
SVG with media queries let you group paths as being used only above a certain rendered size which can prevent artifacts of fine details showing up at very low zooms.
I wish SVG had a mechanism for doing this that didn't involve scripts or css.
It doesn't actually, but it's close.
SVG with media queries let you group paths as being used only above a certain rendered size which can prevent artifacts of fine details showing up at very low zooms.
I wish SVG had a mechanism for doing this that didn't involve scripts or css.
The description of amount of work the author produced, including for the SVG 2 spec, reads like the CV of someone who has been with W3C since 1999 (which is when W3C first started working on SVG according to Wikipedia). It's stunning that the author only started self-learning web dev basics just 3.5 years ago. Whatever she decides to do with SVG, I hope she can easily land a job in the field despite her requirements to do remote work. She clearly has the technical chops, communication skills, and perseverance that tech companies value.
I am working on svg animations right now (on Android, but AFAIK it is pretty much the same on the web).
Tooling is pretty poor at the moment, even though this is changing rapidly with :
https://romannurik.github.io/AndroidIconAnimator/
and
https://shapeshifter.design/
that are quickly starting to cover this ground (but they still need a lot of work).
Animating an svg shape to another in a nice way has been doable for some time, like for example : https://material.uplabs.com/posts/animations-in-pocket-casts
Doing so is really time intensive though as soon as your shapes are not trivial, especially since without these two recent tools, you are left with a sheet of paper as your best instrument ..
I would have gladly paid 20 $ last year for a tool allowing me to efficiently create such an animation.
Tooling is pretty poor at the moment, even though this is changing rapidly with :
https://romannurik.github.io/AndroidIconAnimator/
and
https://shapeshifter.design/
that are quickly starting to cover this ground (but they still need a lot of work).
Animating an svg shape to another in a nice way has been doable for some time, like for example : https://material.uplabs.com/posts/animations-in-pocket-casts
Doing so is really time intensive though as soon as your shapes are not trivial, especially since without these two recent tools, you are left with a sheet of paper as your best instrument ..
I would have gladly paid 20 $ last year for a tool allowing me to efficiently create such an animation.
hey, i'm the guy who is developing shape shifter. glad to see you have been using it. if you have any feature requests or suggestions i'd love to hear them! just file something on GitHub: https://github.com/alexjlockwood/ShapeShifter/issues
p.s. IDK if you have used the tool recently, but i just published an update that makes the tool much easier to use IMO. :)
p.s. IDK if you have used the tool recently, but i just published an update that makes the tool much easier to use IMO. :)
Perhaps http://snapsvg.io/ could work for your use case?
nope, this only allows you to edit an svg with js code.
That's not applicable to another platform.
I need to modify the svgs themselves in order to make them morphable.
That's easier said than done since they need to contain the same instructions in the same order (with only different parameters) and the transition cannot be random.
That's not applicable to another platform.
I need to modify the svgs themselves in order to make them morphable.
That's easier said than done since they need to contain the same instructions in the same order (with only different parameters) and the transition cannot be random.
Would be great if MS and Google hired her to consult on SVG support for email, considering it doesn't exist without image fallback[0].
[0] https://css-tricks.com/a-guide-on-svg-support-in-email
[0] https://css-tricks.com/a-guide-on-svg-support-in-email
SVG always reminds me of JS - a seemingly overcomplicated and slightly ungainly technology that actually just turned out to be ahead of its time.
Back in the bad old days when you had to install the Adobe plugin to view it at all, it was almost useless. But nowadays, almost all browsers have more than adequate native support and it turns out that it's actually very useful as a good way of doing declarative vector graphics (as opposed to the immediate mode world of Canvas). I switched to using SVG for all artwork in my apps about 2 years ago and haven't looked back once - there are no performance issues; I can retheme them via CSS (if loaded as objects rathe than imgs), they look perfect on arbitrary resolution displays, plus animation is trivial when desired. Meanwhile libraries like D3 show just how powerful and performant SVG can be.
So: given a choice between a custom library which implements some kind of vector DOM on top of canvas, and having it baked into the native DOM of the browser with decent performance, I know which I'd rather have.
The biggest problem I've seen in practice is when handling user generated SVGs - the risk of vulnerabilities in the implementations; XSS attacks - and design flaws like billion lol attacks. But such are the risks of using an expressive language like HTML, SVG, or heaven forbid postscript or PDF :)
Back in the bad old days when you had to install the Adobe plugin to view it at all, it was almost useless. But nowadays, almost all browsers have more than adequate native support and it turns out that it's actually very useful as a good way of doing declarative vector graphics (as opposed to the immediate mode world of Canvas). I switched to using SVG for all artwork in my apps about 2 years ago and haven't looked back once - there are no performance issues; I can retheme them via CSS (if loaded as objects rathe than imgs), they look perfect on arbitrary resolution displays, plus animation is trivial when desired. Meanwhile libraries like D3 show just how powerful and performant SVG can be.
So: given a choice between a custom library which implements some kind of vector DOM on top of canvas, and having it baked into the native DOM of the browser with decent performance, I know which I'd rather have.
The biggest problem I've seen in practice is when handling user generated SVGs - the risk of vulnerabilities in the implementations; XSS attacks - and design flaws like billion lol attacks. But such are the risks of using an expressive language like HTML, SVG, or heaven forbid postscript or PDF :)
(that said - I just checked on the health of one of my favourite Mozilla SVG bugs; the fact that it ignores baseline-shift so there's no simple way of vertically centring text over (say) a line in order to draw something like an arrow label. Sadly, 12 years and still open... https://bugzilla.mozilla.org/show_bug.cgi?id=308338)
What tool do you use to produce SVG? What kind of browser compatibility to you require for your creations?
The core of the problem to me, seems to be the absence of a widely supported declarative low level 2D vector format to compile to, likely with closed arced paths* as only vector primitives.
(Point and Lines are 0 and 1 dimensional and need to constructed anyway for display)
Full SVG just seems too high level to be implemented universally, especially when sent in some form to a GPU for parallel evaluation.
Now have a moment of silence for OpenVG https://www.khronos.org/openvg/
Yet there is hope:
http://w3.impa.br/~diego/projects/GanEtAl14/
https://graphics.cs.illinois.edu/sites/default/files/svgpu.p...
https://developer.nvidia.com/nv-path-rendering
* hopefully compatible with Path2D API https://developer.mozilla.org/en-US/docs/Web/API/Path2D/Path...
Full SVG just seems too high level to be implemented universally, especially when sent in some form to a GPU for parallel evaluation.
Now have a moment of silence for OpenVG https://www.khronos.org/openvg/
Yet there is hope:
http://w3.impa.br/~diego/projects/GanEtAl14/
https://graphics.cs.illinois.edu/sites/default/files/svgpu.p...
https://developer.nvidia.com/nv-path-rendering
* hopefully compatible with Path2D API https://developer.mozilla.org/en-US/docs/Web/API/Path2D/Path...
How does Postscript not capture the "widely supported low level format?"
No, I assert that the problem is there is just not a need for serializing vector graphics across the wire for the vast majority of people. Or of authoring graphics in said fashion. Combined with the people best at creating graphics typically best at doing so using a visual toolchain. Which lends itself to the standard toolchain of Photoshop (or whatever application) and just generally does not need to be programmed or to have "clean" output.
Indeed, most graphics are best created at the target resolution that they are needed and using tools that are more akin to the metaphor of painting. See the popularity of the Surface with artists. Now, try to make a program that you interact with using paint brushes, but outputs "clean" vector commands.
If you succeed at that, you will be deserving of whatever computing awards you can get.
No, I assert that the problem is there is just not a need for serializing vector graphics across the wire for the vast majority of people. Or of authoring graphics in said fashion. Combined with the people best at creating graphics typically best at doing so using a visual toolchain. Which lends itself to the standard toolchain of Photoshop (or whatever application) and just generally does not need to be programmed or to have "clean" output.
Indeed, most graphics are best created at the target resolution that they are needed and using tools that are more akin to the metaphor of painting. See the popularity of the Surface with artists. Now, try to make a program that you interact with using paint brushes, but outputs "clean" vector commands.
If you succeed at that, you will be deserving of whatever computing awards you can get.
Meaning ever seen PostScript rendered somewhere natively in a browser?
In the DTP world, the problem does indeed not exist in that way.
most graphics are best created at the target resolution
This paradigm seems to become obsolete to me. With the present adoption rate of HiDPI displays target ratios matter again, not pixels.
Basically were back with displays to the paradigms that print/layout had for centuries and which where tackled in the digital realm before with the first transition from low resolution raster to high resolution print in the mid-70s to 80s with the inception of PostScript and Illustrator (the original core of Adobe, John Warnock) and also MetaFont by Knuth. We're currently in the middle of another transition, now happening on-screen with the transition to non-pixel based authoring for HiDPI displays.
Pixels as authoring targets will probably be seen as a transitional technology/paradigm in a decade or less, placed neatly between paper and true vector displays on one end and Retina+ type screens on the other recent end of an interval spanning only one or two generations in retrospect.
In general things have improved a lot in the last 5 years, SVG is also simply good enough for most things: https://news.ycombinator.com/item?id=6470908
most graphics are best created at the target resolution
This paradigm seems to become obsolete to me. With the present adoption rate of HiDPI displays target ratios matter again, not pixels.
Basically were back with displays to the paradigms that print/layout had for centuries and which where tackled in the digital realm before with the first transition from low resolution raster to high resolution print in the mid-70s to 80s with the inception of PostScript and Illustrator (the original core of Adobe, John Warnock) and also MetaFont by Knuth. We're currently in the middle of another transition, now happening on-screen with the transition to non-pixel based authoring for HiDPI displays.
Pixels as authoring targets will probably be seen as a transitional technology/paradigm in a decade or less, placed neatly between paper and true vector displays on one end and Retina+ type screens on the other recent end of an interval spanning only one or two generations in retrospect.
In general things have improved a lot in the last 5 years, SVG is also simply good enough for most things: https://news.ycombinator.com/item?id=6470908
I wasn't saying pixel level creation. I just said target resolution creation. In general, you design the screen you want. Using tools that let you draw, with the constraint that it is at the resolution you desire.
Am I saying that vector graphics are not desirable? No. Just saying that that is a by product of the tool. If you are making something that can scale up perfectly, great. Most graphics don't. Pretty much period.
Am I saying that vector graphics are not desirable? No. Just saying that that is a by product of the tool. If you are making something that can scale up perfectly, great. Most graphics don't. Pretty much period.
Postscript is higher level than SVG. Postscript is a full imperative programming language for describing pages. SVG was designed (originally by Adobe) to be a lightweight, declarative, XML version of Postscript.
With JavaScript nailed onto the side.
Remember when Adobe was promoting SVG as a superior alternative to Flash? (Before they bought Macromedia of course. Then it was the red-headed bastard stepchild sitting out on the back porch in the rain.)
Remember when Adobe was promoting SVG as a superior alternative to Flash? (Before they bought Macromedia of course. Then it was the red-headed bastard stepchild sitting out on the back porch in the rain.)
> there is just not a need for […] authoring graphics in said fashion
You say that like Adobe Illustrator has existed without reason for 30 years.
You say that like Adobe Illustrator has existed without reason for 30 years.
Illustrator is a graphical editing tool. It outputs vector graphics, but it is not an authoring tool for the vector representation. At least, not in the way that requires knowing the spec.
Which is my point. Few people that are using Illustrator know anything about SVG.
I think you just misunderstood my sentence, so I apologize if that is the case. By "authoring graphics in said fashion", what I mean is authoring using text. Directly specifying the vector primitives, which is what SVG is ultimately for. Is there a better way of saying that?
Which is my point. Few people that are using Illustrator know anything about SVG.
I think you just misunderstood my sentence, so I apologize if that is the case. By "authoring graphics in said fashion", what I mean is authoring using text. Directly specifying the vector primitives, which is what SVG is ultimately for. Is there a better way of saying that?
I agree that, for the end-user, a low-level format like PostScript is perfect. No need to preserve structure. But tools like Illustrator need to preserve some structure. Otherwise it becomes very difficult to make edits. (Imagine reflowing text in a PostScript file – next to impossible!)
Even Photoshop preserves lots of structure these days, so you can perform non-destructive edits.
SVG's other use case is interactive animations. You could equally use Canvas for this, but it's nice to be able to import resources directly from e.g. Inkscape, and manipulate them using the DOM. Easier to build an animation authoring tool around structured SVG than unstructured PostScript or Canvas.
Even Photoshop preserves lots of structure these days, so you can perform non-destructive edits.
SVG's other use case is interactive animations. You could equally use Canvas for this, but it's nice to be able to import resources directly from e.g. Inkscape, and manipulate them using the DOM. Easier to build an animation authoring tool around structured SVG than unstructured PostScript or Canvas.
The interactive diagrams is my main (only?) use for SVG. Technically I could write code for everything, but just being able to draw it out in Inkscape is a superior experience.
So here's a question:
JSON is to XML what ___ is to SVG. What is in the blank?
There's just so much complexity in even the 1.1 spec.
Patterns, for example, are given the default of specifying the width and height of the area to be repeated in objectBoundingBox units. But the arbitrarily complex content has its units defined in terms of the userspace units derived from the context in which the pattern itself is used.
Now, if you play around with patterns for a bit you can certainly figure out the logic of those defaults. Most likely the author doesn't want the aspect ratio of the pattern content to change based on the width/height specified for the pattern viewbox. Hence patternContentUnits defaults to "userSpaceOnUse". On the other hand, the author likely wants to control the total number of columns/rows that will be displayed. Hence patternUnits defaults to "objectBoundingBox", where you can do the math for 1/width for rows and 1/height for columns.
But then when you try to do actual work using those defaults-- say, filling a rectangle with a pattern that displays four small circles as "nails" in the corners of the rectangle-- it doesn't work. The patternUnits attribute isn't expressive enough to let you specify a way to attach each pattern iteration to a corner of the shape. You can achieve that for a particular bounding box, but it isn't easy. So the logical though complex default isn't particularly expressive in practice, and the more sane, less expressive way to do patterns requires non-default attributes.
I run into similar such problems with many of the SVG 1.1 features. There's an incredible amount of complexity, but not a matching amount of expressivity gained for it. Even something like grabbing or setting a value for height/width/x/y is made more complex because the DOM is storing both a base value and an additional value should the user happen to have specified declarative animation on the element. But then declarative animation isn't implemented in all browsers after all this time-- nor is it as easy to work with as the burgeoning web animations API.
JSON is to XML what ___ is to SVG. What is in the blank?
There's just so much complexity in even the 1.1 spec.
Patterns, for example, are given the default of specifying the width and height of the area to be repeated in objectBoundingBox units. But the arbitrarily complex content has its units defined in terms of the userspace units derived from the context in which the pattern itself is used.
Now, if you play around with patterns for a bit you can certainly figure out the logic of those defaults. Most likely the author doesn't want the aspect ratio of the pattern content to change based on the width/height specified for the pattern viewbox. Hence patternContentUnits defaults to "userSpaceOnUse". On the other hand, the author likely wants to control the total number of columns/rows that will be displayed. Hence patternUnits defaults to "objectBoundingBox", where you can do the math for 1/width for rows and 1/height for columns.
But then when you try to do actual work using those defaults-- say, filling a rectangle with a pattern that displays four small circles as "nails" in the corners of the rectangle-- it doesn't work. The patternUnits attribute isn't expressive enough to let you specify a way to attach each pattern iteration to a corner of the shape. You can achieve that for a particular bounding box, but it isn't easy. So the logical though complex default isn't particularly expressive in practice, and the more sane, less expressive way to do patterns requires non-default attributes.
I run into similar such problems with many of the SVG 1.1 features. There's an incredible amount of complexity, but not a matching amount of expressivity gained for it. Even something like grabbing or setting a value for height/width/x/y is made more complex because the DOM is storing both a base value and an additional value should the user happen to have specified declarative animation on the element. But then declarative animation isn't implemented in all browsers after all this time-- nor is it as easy to work with as the burgeoning web animations API.
Last year, I invented IconVG, a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.
IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc.
The announcement is at https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p... and quoting from that:
"The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]...
The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."
IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc.
The announcement is at https://groups.google.com/forum/#!topic/golang-nuts/LciLeI5p... and quoting from that:
"The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]...
The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."
Thats really cool, but its impossible to discover and learn about hidden away in a dusty old thread on the golang-nuts mailing list.
If you want your project to become popular & used by a wider audience, it would be totally worth getting a domain and making a website for it. Ideally the site would host demos and links to the spec / implementations - but even something simple with the content described in that thread would be a good start.
If you want your project to become popular & used by a wider audience, it would be totally worth getting a domain and making a website for it. Ideally the site would host demos and links to the spec / implementations - but even something simple with the content described in that thread would be a good start.
I discovered it by reading this page while browsing the shiny package: https://godoc.org/golang.org/x/exp/shiny/iconvg
I think the documentation is quite good.
What you ask of Nigel is similar to what you see in the article. Should he spend his own resources to maintain a domain and website? How far does one take this?
I think the documentation is quite good.
What you ask of Nigel is similar to what you see in the article. Should he spend his own resources to maintain a domain and website? How far does one take this?
Even just a github repo with a `gh-pages` branch and simple static site can do wonders for a project.
JSON is to XML what ___ is to SVG. What is in the blank?
It's not exciting or clever, but HTML5 Canvas fills in that blank.
It'a a minimal API that was designed by Apple to be just good enough to make Mac OS X 10.4 desktop widgets possible to implement in JavaScript. Canvas has a straightforward mapping to the big platform 2D APIs -- CoreGraphics, Cairo, Direct2D. The bitmap data interfaces are an ugly but in practice mostly satisfactory escape hatch when you need to draw something the API doesn't include.
Both SVG and CSS are failed specs in my mind due to what you succinctly describe as "incredible complexity without matching expressivity". The difference is that CSS doesn't have an alternative, so everyone tries to live with it.
It's not exciting or clever, but HTML5 Canvas fills in that blank.
It'a a minimal API that was designed by Apple to be just good enough to make Mac OS X 10.4 desktop widgets possible to implement in JavaScript. Canvas has a straightforward mapping to the big platform 2D APIs -- CoreGraphics, Cairo, Direct2D. The bitmap data interfaces are an ugly but in practice mostly satisfactory escape hatch when you need to draw something the API doesn't include.
Both SVG and CSS are failed specs in my mind due to what you succinctly describe as "incredible complexity without matching expressivity". The difference is that CSS doesn't have an alternative, so everyone tries to live with it.
HTML5 canvas doesn't fill in the blank IMO because it's too low-level. (Plus, its performance scales with canvas size where SVG's performance scales with the number of objects.)
Example: suppose I inject the following innerHTML into an svg: <rect width="80" height="80"><title>The incredible disappearing rect!</title></rect>. Now I set rectElem to that rect element and do this: rectElem.animate( { opacity: [1, 0, 1] }, { duration: 5000, iterations: Infinity } );
That's actually pretty expressive. The unnecessary complexity is unfortunately even apparent here, though: a) the interrelationship between xml attrs for width/height and css property for opacity (SVG2 apparently simplifies this by making all attrs available as css properties), and b) the <title> tag points to the fact that SVG is in its own separate XML namespace, which causes all kinds of pain.
Example: suppose I inject the following innerHTML into an svg: <rect width="80" height="80"><title>The incredible disappearing rect!</title></rect>. Now I set rectElem to that rect element and do this: rectElem.animate( { opacity: [1, 0, 1] }, { duration: 5000, iterations: Infinity } );
That's actually pretty expressive. The unnecessary complexity is unfortunately even apparent here, though: a) the interrelationship between xml attrs for width/height and css property for opacity (SVG2 apparently simplifies this by making all attrs available as css properties), and b) the <title> tag points to the fact that SVG is in its own separate XML namespace, which causes all kinds of pain.
HTML5 Canvas is the least accessible thing to be put on the Web since Flash.
If you render text inside a canvas element, you end up with a picture of text. You can't screen-read it, you can't re-flow it, you can't even select it!
If you render text inside a canvas element, you end up with a picture of text. You can't screen-read it, you can't re-flow it, you can't even select it!
That is taking quite a dim view of what you can achieve with browsers and screen readers to make pages accessible.
The key is to decide whether your canvas is being used as a dynamic pixel buffer or as a static image after it has been painted (akin to an img tag.) If it's static, just supply alt text and you're accessible.
If you have a dynamic canvas, you can maintain a visually hidden div alongside the canvas that you set to role="alert" aria-live="assertive". Add text to the div as things happen in the canvas that describe the situation. Any screen reader watching the page will read out the text live as you make updates.
There is always a way to do right by your users if you care, some things just take more work than others.
The key is to decide whether your canvas is being used as a dynamic pixel buffer or as a static image after it has been painted (akin to an img tag.) If it's static, just supply alt text and you're accessible.
If you have a dynamic canvas, you can maintain a visually hidden div alongside the canvas that you set to role="alert" aria-live="assertive". Add text to the div as things happen in the canvas that describe the situation. Any screen reader watching the page will read out the text live as you make updates.
There is always a way to do right by your users if you care, some things just take more work than others.
The problem is your proposal is that it's a bit of a hack.
So when you render with the canvas it's pretty raw, much like if you were rendering a scene using native painting with a native language (SDL, OpenGL, DirectX, etc). The typical pattern here is you setup an animation and, sometimes, an update loop (though update loop is a little awkward with canvas but I digress). These loops fire constantly to update the scene and repaint everything.
When you bring the DOM into it the DOM doesn't work like that. The DOM is a completely different way to render everything.
So when do you move your DOM overlays onto the canvas? In the update loop? Then control their display via the render loop? Now you have some trouble. Depending on what you're doing to the DOM object may repaint the entire window, not just your canvas. So now you have more overhead and you're losing performance.
But wait it gets even more fun. While your canvas animations progress with every `requestAnimationFrame` the DOM is different. The DOM won't get updated until the next next tick if you're making changes in your render loop (so once the current `requestAnimationFrame` ends then the DOM gets updated). Since the DOM isn't updated in the same time you have to compensate for that. Also, if you're updating positions in an update loop (pretty common) and you update DOM properties here, now the DOM will be updated after the update loop is run and before the next render loop. Either way if you run into performance slowdowns this can become very noticeable.
Ultimately you're taking two very different ways of handling drawing and you're trying to force them together to support accessibility. The better solution would be to build more of these capabilities into the canvas and its APIs itself.
So when you render with the canvas it's pretty raw, much like if you were rendering a scene using native painting with a native language (SDL, OpenGL, DirectX, etc). The typical pattern here is you setup an animation and, sometimes, an update loop (though update loop is a little awkward with canvas but I digress). These loops fire constantly to update the scene and repaint everything.
When you bring the DOM into it the DOM doesn't work like that. The DOM is a completely different way to render everything.
So when do you move your DOM overlays onto the canvas? In the update loop? Then control their display via the render loop? Now you have some trouble. Depending on what you're doing to the DOM object may repaint the entire window, not just your canvas. So now you have more overhead and you're losing performance.
But wait it gets even more fun. While your canvas animations progress with every `requestAnimationFrame` the DOM is different. The DOM won't get updated until the next next tick if you're making changes in your render loop (so once the current `requestAnimationFrame` ends then the DOM gets updated). Since the DOM isn't updated in the same time you have to compensate for that. Also, if you're updating positions in an update loop (pretty common) and you update DOM properties here, now the DOM will be updated after the update loop is run and before the next render loop. Either way if you run into performance slowdowns this can become very noticeable.
Ultimately you're taking two very different ways of handling drawing and you're trying to force them together to support accessibility. The better solution would be to build more of these capabilities into the canvas and its APIs itself.
I guess what is a hack and what is not depends 1) on how much you expect the browser vendors to do for you, and 2) on how tortured your code looks after you get the effect you want from the browser.
I'll be first in line to call DOM, HTML, and CSS a hot mess and a frequent head-scratcher. But, the WAI-ARIA architecture turned out very nicely. I don't know about you, but I think the ability of the content creator to add metadata to markup to explain aurally, and in context, what that markup means is brilliant and inspired.
Equally inspired is the Web Content Accessibility Guidelines (WCAG)[1]. The WCAG gives you the right way to think as a web developer about content and how to be respectful of your users with disabilities and make a simulateously navigable and content rich page for all users. It teaches you not only to think about and cater to screen-reader (blind) users, but also low-vision users, color blind users, mouse-only users, keyboard-only users, and cognitively impaired users.
Here's what WCAG says about how to 'show' images to screen reader users, for instance:
> 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
In the how to understand 1.1.1 section, it talks about canvas content like yours and how it should be 'read' by screen readers:
> Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, additional descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information.
What that basically says is that the user needs to be able to see to experience the content, so just slap alt text on your canvas tag. As unsatisfactory as that sounds to you and me, to a screen reader user, having that alt text shows respect because without it the page doesn't make any sense when it is read out to them by the screen reader - there's literally a big blank spot conceptually where the canvas sits without the alt text. No, they can't reasonably play your canvas game, but at least they understand that something is there when they visit your page.
Now, what I was describing earlier was a canvas that is painted with text and graphics that could conceivably be narrated to the screen reader user. (Maybe a turn-based rogue-like, for instance.) In that case, I'd use WAI-ARIA attributes to cause a visibly hidden div to be read by the screen reader whenever I update its textual content. All your concerns about my div causing the page to reflow and repaint are not valid because my content does not affect flow or paints. Use something ninja like HTML5 Boilerplate's visuallyhidden CSS class to make content 'appear' to screen reader software but be completely hidden on the displayed page:
[1] https://www.w3.org/TR/WCAG20/
[2] https://www.nvaccess.org/
I'll be first in line to call DOM, HTML, and CSS a hot mess and a frequent head-scratcher. But, the WAI-ARIA architecture turned out very nicely. I don't know about you, but I think the ability of the content creator to add metadata to markup to explain aurally, and in context, what that markup means is brilliant and inspired.
Equally inspired is the Web Content Accessibility Guidelines (WCAG)[1]. The WCAG gives you the right way to think as a web developer about content and how to be respectful of your users with disabilities and make a simulateously navigable and content rich page for all users. It teaches you not only to think about and cater to screen-reader (blind) users, but also low-vision users, color blind users, mouse-only users, keyboard-only users, and cognitively impaired users.
Here's what WCAG says about how to 'show' images to screen reader users, for instance:
> 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
In the how to understand 1.1.1 section, it talks about canvas content like yours and how it should be 'read' by screen readers:
> Sometimes content is primarily intended to create a specific sensory experience that words cannot fully capture. Examples include a symphony performance, works of visual art etc. For such content, text alternatives at least identify the non-text content with a descriptive label and where possible, additional descriptive text. If the reason for including the content in the page is known and can be described it is helpful to include that information.
What that basically says is that the user needs to be able to see to experience the content, so just slap alt text on your canvas tag. As unsatisfactory as that sounds to you and me, to a screen reader user, having that alt text shows respect because without it the page doesn't make any sense when it is read out to them by the screen reader - there's literally a big blank spot conceptually where the canvas sits without the alt text. No, they can't reasonably play your canvas game, but at least they understand that something is there when they visit your page.
Now, what I was describing earlier was a canvas that is painted with text and graphics that could conceivably be narrated to the screen reader user. (Maybe a turn-based rogue-like, for instance.) In that case, I'd use WAI-ARIA attributes to cause a visibly hidden div to be read by the screen reader whenever I update its textual content. All your concerns about my div causing the page to reflow and repaint are not valid because my content does not affect flow or paints. Use something ninja like HTML5 Boilerplate's visuallyhidden CSS class to make content 'appear' to screen reader software but be completely hidden on the displayed page:
.visuallyhidden {
border: 0;
clip: rect(0 0 0 0);
clip-path: inset(50%);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
white-space: nowrap; /* 1 */
}
[1] https://www.w3.org/TR/WCAG20/
[2] https://www.nvaccess.org/
To add on to the text note, it's actually even more annoying with Canvas to draw it correctly. None of the major browsers implement a TextMetrics object (the return of ctx.measureText) that has anything more than the width of the text. https://developer.mozilla.org/en-US/docs/Web/API/TextMetrics
How anyone thought it was OK not to ship that is beyond me, but it means that when laying out content on the canvas you have to write a hack for the font height and hope it's good enough for most cases. I think there is a polyfill available but I believe it works by rendering the text in SVG and measuring it there which seems to defeat the purpose of doing it on canvas.
How anyone thought it was OK not to ship that is beyond me, but it means that when laying out content on the canvas you have to write a hack for the font height and hope it's good enough for most cases. I think there is a polyfill available but I believe it works by rendering the text in SVG and measuring it there which seems to defeat the purpose of doing it on canvas.
It's easy enough to overlay text in HTML though.
That your solution to the problem is a truly hideous hack, speaks volumes.
Hideous hack? Use abs positioning, and overlay. Let's see, you have a scripting language host in the presentation layer and built-in first class methods to draw HTML elements and to canvas. The horror!
Sorry but I'm also going to consider that a pretty awful hack. If you're going through the trouble of setting up an animation loop for rendering graphics you need to have your text in the same space. If you don't now you have to bridge this gap of two different rendering worlds.
There are abstractions and techniques to overlay html elements over the canvas and sorta meld them together, sure. But they're rendered and updated in astonishingly different fashions that don't really go well together.
This is sorta like writing a game using a rendering technology like OpenGL but then sticking, say, a win32 label control on top of the rendered OpenGL screen. They both have very different patterns of control.
There are abstractions and techniques to overlay html elements over the canvas and sorta meld them together, sure. But they're rendered and updated in astonishingly different fashions that don't really go well together.
This is sorta like writing a game using a rendering technology like OpenGL but then sticking, say, a win32 label control on top of the rendered OpenGL screen. They both have very different patterns of control.
Then just write the text in canvas, if it's a game. The original poster said that canvas text was not accessible and didn't wrap. I don't think screen readers and tightly synced game loops go together well. And is wrapping text some big problem in the game world?
Ever played a game with a chat box?
I've played one implemented on top of Canvas and it was horrible.
I've played one implemented on top of Canvas and it was horrible.
SVG is a data format; Canvas is an API. They're only interchangeable in limited use cases.
JavaScript is a programming language, yet its subset JSON is a data format.
PostScript is a programming language, yet it looks like a data format to most applications.
The web is supposed to be about hyperlinked documents, yet it's mostly about executing JavaScript applications these days.
The blurred lines between data and code are the most exciting thing about this whole field, if you ask me!
PostScript is a programming language, yet it looks like a data format to most applications.
The web is supposed to be about hyperlinked documents, yet it's mostly about executing JavaScript applications these days.
The blurred lines between data and code are the most exciting thing about this whole field, if you ask me!
JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant.
PostScript is a terrible intermediate graphics format. It is not structured like how SVG is, and thus does not lend itself well to editing. Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates.
You're right that Canvas is analogous to PostScript; Canvas also would make a terrible intermediate format. Sure, we could use it as one; it would certainly be a more universal final format than SVG; but then, what's wrong with PostScript there? It's certainly less verbose.
Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.
PostScript is a terrible intermediate graphics format. It is not structured like how SVG is, and thus does not lend itself well to editing. Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates.
You're right that Canvas is analogous to PostScript; Canvas also would make a terrible intermediate format. Sure, we could use it as one; it would certainly be a more universal final format than SVG; but then, what's wrong with PostScript there? It's certainly less verbose.
Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.
> JSON is based on (not a subset of) a purely declarative and structural portion of JavaScript. They really have nothing to do with each other except some surface syntax, which is wholly irrelevant.
That's an ahistorical view that completely ignores the only reason why JSON became popular: it could be loaded into a browser using eval() or script tags at a time when JS engines were slow and limited.
If the JS-compatible syntax were irrelevant, surely everyone would have standardized on one of the existing tidier formats?
> Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates.
This is good. Imagine if Adobe had designed PostScript back in 1983 using the SVG design mentality. They could not have foreseen all the applications for PostScript. The original text flow model would have rapidly become inadequate, and they would have been forced to pile on hacks into the standard -- just as happened with CSS.
Between PostScript and HTML+CSS, the former is a much more useful industry standard. It's relatively easy to implement a PostScript interpreter from scratch. It's practically impossible to build a new HTML+CSS renderer.
> Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.
You'll be waiting for a while. Users will keep wanting applications that do more, not less.
That's an ahistorical view that completely ignores the only reason why JSON became popular: it could be loaded into a browser using eval() or script tags at a time when JS engines were slow and limited.
If the JS-compatible syntax were irrelevant, surely everyone would have standardized on one of the existing tidier formats?
> Consider the basic example of text: there is no such thing as a "text box" or "flow" in PostScript; rather, individual letters are placed at coordinates.
This is good. Imagine if Adobe had designed PostScript back in 1983 using the SVG design mentality. They could not have foreseen all the applications for PostScript. The original text flow model would have rapidly become inadequate, and they would have been forced to pile on hacks into the standard -- just as happened with CSS.
Between PostScript and HTML+CSS, the former is a much more useful industry standard. It's relatively easy to implement a PostScript interpreter from scratch. It's practically impossible to build a new HTML+CSS renderer.
> Blurring the lines between data and code is a tarpit. I look forward to the day it's universally recognized to have been a dead end in the evolution of our field.
You'll be waiting for a while. Users will keep wanting applications that do more, not less.
> it could be loaded into a browser using eval()
That's unrelated to the code/data distinction. But it does elucidate an important downfall of blurring code & data: using eval() opened web applications up to major security holes. (Not to mention it was incorrect, JSON won't cleanly round-trip JS even with JSON.parse.)
JSON is plain old data, nothing more, nothing less. Sure, I could replace all SVG tags with curly braces; that doesn't make it code.
> Users will keep wanting applications that do more, not less.
The ability to author vector graphics at a high level being a prime example of something more, that is not possible with a Turing tarpit of a data format like PostScript or JavaScript with lots of Canvas instructions. Applications like Inkscape are only possible because of rich data formats like SVG.
Note the lack of authoring tools -- both for vector graphics and documents -- which work natively with unattributed PostScript. That's because its nature, as code, obscures all structure. It makes for a mediocre final format due to (as you point out) its ease of implementation, nothing more. And even there, PDF, which is not interpreted, has proven superior. JS+Canvas would suffer the same issues.
That's unrelated to the code/data distinction. But it does elucidate an important downfall of blurring code & data: using eval() opened web applications up to major security holes. (Not to mention it was incorrect, JSON won't cleanly round-trip JS even with JSON.parse.)
JSON is plain old data, nothing more, nothing less. Sure, I could replace all SVG tags with curly braces; that doesn't make it code.
> Users will keep wanting applications that do more, not less.
The ability to author vector graphics at a high level being a prime example of something more, that is not possible with a Turing tarpit of a data format like PostScript or JavaScript with lots of Canvas instructions. Applications like Inkscape are only possible because of rich data formats like SVG.
Note the lack of authoring tools -- both for vector graphics and documents -- which work natively with unattributed PostScript. That's because its nature, as code, obscures all structure. It makes for a mediocre final format due to (as you point out) its ease of implementation, nothing more. And even there, PDF, which is not interpreted, has proven superior. JS+Canvas would suffer the same issues.
Aren't .psd and .ai formats based off of PostScript?
.PSD certainly not. Why would it?
But .AI has originally been PostScript and currently is PDF. Pretty much in the same way as Inkscape uses SVG as its native format – application-specific things are encoded as additional data on objects which can (usually) be safely ignored by other applications rendering the same file format.
But .AI has originally been PostScript and currently is PDF. Pretty much in the same way as Inkscape uses SVG as its native format – application-specific things are encoded as additional data on objects which can (usually) be safely ignored by other applications rendering the same file format.
> The web is supposed to be about hyperlinked documents, yet it's mostly about executing JavaScript applications these days.
Is it? Most of the content people use the web for is still mostly hyperlinked documents. Although it's often obfuscated by a bunch of javascript.
Is it? Most of the content people use the web for is still mostly hyperlinked documents. Although it's often obfuscated by a bunch of javascript.
Fabric.js helps a bit with that. It can export/import a canvas to either JSON or SVG.
http://fabricjs.com/fabric-intro-part-3#deserialization
http://fabricjs.com/fabric-intro-part-3#deserialization
Canvas is written with a imperative (Turning complete) language.
SVG is declarative. Pretty large difference.
SVG is declarative. Pretty large difference.
PostScript/PDF is also an imperative language. Yet it works for billions of documents. Users don't care about Turing completeness.
"Declarative" is one of those concepts that sounds highly desirable until you start thinking about extensibility and future inter-implementation compatibility. The sad tale of the SVG 2 standard, as told in the original post, is a textbook example.
"Declarative" is one of those concepts that sounds highly desirable until you start thinking about extensibility and future inter-implementation compatibility. The sad tale of the SVG 2 standard, as told in the original post, is a textbook example.
PDF is not a Turing-complete, but Postscript is. PDF removed several features which made Postscript a programming language.
That was a great approach IMO. First build a flexible toolset that allowed the market explore the problem space, then, a decade later, collect the learnings into a new, narrower standard.
If SVG 2 were like that, it probably would have got a warmer reception from browser vendors. But standards committees creating declarative formats have never been very interested in removing features.
If SVG 2 were like that, it probably would have got a warmer reception from browser vendors. But standards committees creating declarative formats have never been very interested in removing features.
I'm not sure I would call PDF a narrower standard, one of the problems with it is Adobe couldn't stop themselves adding new features.
SVG is a declarative markup language that can include a Turing complete scripting language. I mean it is a pretty large difference, and it's even a pretty large difference between how you described SVG and how I did it, and neither one of us is complete.
For graphics and animated graphics, no Turning language needed. (Interactive graphics of course is different.)
Moreover, very few SVG viewers would interpret embedded JS.
Moreover, very few SVG viewers would interpret embedded JS.
for animated graphics no Turing language needed - true. However a Turing complete language can sure make things easier.
Also for animated graphics some things that are not interactive (if we defined interactive as meaning with user interaction) like randomness for example - need something similar to a programming language to do it.
Also for animated graphics some things that are not interactive (if we defined interactive as meaning with user interaction) like randomness for example - need something similar to a programming language to do it.
The problem is that JSON didn't come into being to replace XML. JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects. (If there is an alternative history here that is compelling, I'll accept it. Will be hard, though, because I swear JSON was essentially an accepted standard as soon as people found they could write out a JS object directly.)
So, is there another language that lets you script graphics easily? PostScript would have come close, maybe. METAPOST definitely gets close, though folks are afraid of it.
I think my vote would ultimately end up being METAPOST, as far as capabilities go. Nothing, if we are looking for a popularity contest. And, well, nothing if we are looking for "works well in the browser".
So, is there another language that lets you script graphics easily? PostScript would have come close, maybe. METAPOST definitely gets close, though folks are afraid of it.
I think my vote would ultimately end up being METAPOST, as far as capabilities go. Nothing, if we are looking for a popularity contest. And, well, nothing if we are looking for "works well in the browser".
> JSON exists only because it was basically the JS literal syntax, and people needed easy ways to instantiate javascript objects.
JSON is an interchange format that, while it's based off a subset of JavaScript, was created as the authors were looking for a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use and since JavaScript was already there they just lifted that.
I'm not sure I get the "needed easy ways to instantiate javascript objects". I don't see that anywhere and ECMAScript 3 was out at the time which let you instantiate them pretty easily. So maybe I misunderstand your meaning?
JSON is an interchange format that, while it's based off a subset of JavaScript, was created as the authors were looking for a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use and since JavaScript was already there they just lifted that.
I'm not sure I get the "needed easy ways to instantiate javascript objects". I don't see that anywhere and ECMAScript 3 was out at the time which let you instantiate them pretty easily. So maybe I misunderstand your meaning?
> a way to send data between the browser and the server without Flash swifts or Java applets that was small and easy to use
And because they hated angle brackets. XML already filled that void.
And because they hated angle brackets. XML already filled that void.
XML wouldn't have filled the void well for JavaScript though. Their goal was to send data back and forth and would ultimately need to be processed and rendered by JavaScript. Easiest way to do that is to just send a JavaScript object back and forth.
It would have been a lot cheaper to parse JSON into JavaScript objects especially back then on the more limited hardware than trying to parse XML.
It would have been a lot cheaper to parse JSON into JavaScript objects especially back then on the more limited hardware than trying to parse XML.
Pretty soon with the birth of JSON everyone stopped using eval() because of obvious security concerns (eval is evil) and JSON parsers before JSON.parse() were doing the heavy lifting handwritten in JS.
That was also the time when XML/XHTML on the web wasn't as disregarded as today. Browsers are XML parsing software. They exposed JS Interfaces for these XML parsers. And a query interface. And the DOM. Etc.
My thesis: The data to send mostly matches a tree of structs and arrays and values which we use in programming languages. XML is not the perfect vessel for that, it's better used as a document format. XML of course was misused as a configuration format in the decade before, leading to the backlash.
That was also the time when XML/XHTML on the web wasn't as disregarded as today. Browsers are XML parsing software. They exposed JS Interfaces for these XML parsers. And a query interface. And the DOM. Etc.
My thesis: The data to send mostly matches a tree of structs and arrays and values which we use in programming languages. XML is not the perfect vessel for that, it's better used as a document format. XML of course was misused as a configuration format in the decade before, leading to the backlash.
> XML wouldn't have filled the void well for JavaScript though
This isn't hypothetical. It did fill that void before we had JSON, it's what the X in AJAX stood for. Browsers were parsing xml before javascript existed.
In hindsight, JSON was the first sign of the wheel reinvention that was to come from the javascript world.
This isn't hypothetical. It did fill that void before we had JSON, it's what the X in AJAX stood for. Browsers were parsing xml before javascript existed.
In hindsight, JSON was the first sign of the wheel reinvention that was to come from the javascript world.
I think you missed the "well" in my quote (no one said it was hypothetical). Naturally the XMLHttpRequest / AJAX was used with XML first. Microsoft were the ones to introduce it to do exactly that; work with their exchange server's XML.
This is why I said "well". XML isn't a perfect fit into JavaScript's existing objects. It's awkward. Mozilla, imperfectly, copied the interface Microsoft came up with to have a sort of standard and 4 months after that Crockford started using JSON[1]. I don't see much history of applications beyond Microsoft's and a few edge cases that really used XML here; most of what I can find online had a lot of people's first usage of AJAX with JSON or plain text. But I'll admit it's very difficult to find solid data.
But ultimately XMLHttpRequest came out, in its very first ActiveX form in IE, in March 1999 and Crockford started playing with JSON in April 2001. Wikipedia claims XMLHttpRequest didn't become a de facto standard until 2004 when other browsers started adopting it[2] so I'm not convinced it was used for very much XML to begin with.
[1] https://www.youtube.com/watch?v=-C-JoyNuQJs
[2] https://en.wikipedia.org/wiki/XMLHttpRequest
This is why I said "well". XML isn't a perfect fit into JavaScript's existing objects. It's awkward. Mozilla, imperfectly, copied the interface Microsoft came up with to have a sort of standard and 4 months after that Crockford started using JSON[1]. I don't see much history of applications beyond Microsoft's and a few edge cases that really used XML here; most of what I can find online had a lot of people's first usage of AJAX with JSON or plain text. But I'll admit it's very difficult to find solid data.
But ultimately XMLHttpRequest came out, in its very first ActiveX form in IE, in March 1999 and Crockford started playing with JSON in April 2001. Wikipedia claims XMLHttpRequest didn't become a de facto standard until 2004 when other browsers started adopting it[2] so I'm not convinced it was used for very much XML to begin with.
[1] https://www.youtube.com/watch?v=-C-JoyNuQJs
[2] https://en.wikipedia.org/wiki/XMLHttpRequest
Actually, the easiest way is to just send HTML down to the browser. This was the rallying cry of XHTML for a while. You have client side code that calls for an update to a section of the page, and the framework sends down the necessary html to replace it.
It was common to inline a server object into a script tag using the literal syntax. As you say, this used the literal syntax that was supported at the time.
Ajax came and provided async to get data. But the rendering of the page also has dynamic data, and there it has long been easy to put data into objects.
Ajax came and provided async to get data. But the rendering of the page also has dynamic data, and there it has long been easy to put data into objects.
It's perhaps not the answer you are looking for, but spending a couple of evenings learning PostScript (as a programming language) is eye opening.
I just finished suggesting that in a sibling post. :)
For examples of METAPOST, see http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.h...
For examples of Postscript, see https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Example...
Note that for the postscript examples, if you open them in "preview" or other graphical program, it will show you the graphics. If you open it in a text editor, you will see the code.
For examples of METAPOST, see http://tex.loria.fr/prod-graph/zoonekynd/metapost/metapost.h...
For examples of Postscript, see https://atrey.karlin.mff.cuni.cz/~milanek/PostScript/Example...
Note that for the postscript examples, if you open them in "preview" or other graphical program, it will show you the graphics. If you open it in a text editor, you will see the code.
Here's a visual PostScript programming and debugging environment I wrote in PostScript for the NeWS window system in 1989.
http://www.donhopkins.com/drupal/node/97
https://www.youtube.com/watch?v=iuC_DDgQmsM
http://www.donhopkins.com/drupal/node/97
https://www.youtube.com/watch?v=iuC_DDgQmsM
I would love to have something like TikZ for the browser.
> There's just so much complexity in even the 1.1 spec.
Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity over 1.1, which I'm not sure is true. There is some new stuff, but also a lot of edge cases simplified and entire bodies of cruft ripped out (for example, XML DTDs and all associated baggage are gone).
Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity over 1.1, which I'm not sure is true. There is some new stuff, but also a lot of edge cases simplified and entire bodies of cruft ripped out (for example, XML DTDs and all associated baggage are gone).
Yes, that's what I meant. Off the top of my head: 2.0 adds mesh gradients, a "bearing" command to path data, text that wraps (or possibly fills a cavity/shape, can't remember), manual z-ordering, and probably other new features that I didn't notice.
However, it sounds like the browsers have essentially rejected a lot of those new features. If the idea is that they instead use the 2.0 spec only for the clarifications and cruft cleanup that you mention, that would reduce complexity and be a good thing.
However, it sounds like the browsers have essentially rejected a lot of those new features. If the idea is that they instead use the 2.0 spec only for the clarifications and cruft cleanup that you mention, that would reduce complexity and be a good thing.
Some of the features, like mesh gradient have polyfills.
Polyfills are the only way this chicken and egg problem will be solved, if widely used browser vendors will eventually implement the standards.
Polyfills are the only way this chicken and egg problem will be solved, if widely used browser vendors will eventually implement the standards.
I'm only speculating, but the problem may be the complexity of the paint server interface. Using it requires FuncIRIs which-- as one commenter on another thread pointed out-- can cause name collisions with inline SVGs.
You could of course abstract away that problem with javascript post-processing-- but then you have yet more complexity, this time for a problem that doesn't exist in the domain of CSS.
That limits the expressivity of the feature. For example, I wouldn't be able to just play around with SVG mesh gradients inside about:blank in Firefox due to a deeper problem with resolving FuncIRIs. Whereas I can trivially create a CSS gradient there and experiment with them.
You could of course abstract away that problem with javascript post-processing-- but then you have yet more complexity, this time for a problem that doesn't exist in the domain of CSS.
That limits the expressivity of the feature. For example, I wouldn't be able to just play around with SVG mesh gradients inside about:blank in Firefox due to a deeper problem with resolving FuncIRIs. Whereas I can trivially create a CSS gradient there and experiment with them.
Android Vector Drawables? If you manage to ignore the use of namespaces for attributes, which seems to account for half the file size for smaller files... :-/
not a serious reply, but while we are listing out SVG alternatives, heres an obscure one named IDEAL[1] that came with System V UNIX. (linked: the manual in postscript format)
the basic vector primative in IDEAL is a complex number, for making rotations "easier". The language itself is one of the few examples of a fully constraints oriented language. functions rather than taking input parameters, simply have free variables. you can supply constants for any of them and the system will resolve when there is only one possible solution. the output of IDEAL is dvi which could be fed into TROFF to print.
[1]: https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps
the basic vector primative in IDEAL is a complex number, for making rotations "easier". The language itself is one of the few examples of a fully constraints oriented language. functions rather than taking input parameters, simply have free variables. you can supply constants for any of them and the system will resolve when there is only one possible solution. the output of IDEAL is dvi which could be fed into TROFF to print.
[1]: https://web.cecs.pdx.edu/~trent/gnu/groff/103.ps
I empathize. I feel like my work in implementing insurance programs & payday loan portals is of low value to society, yet it pays the bills. Meanwhile I'd much rather focus fully on my project to implement a WASM jit for Lua. That has future potential alone due to WASM unicorns wanting to open up to being useful as a JIT target
Sort of flies in the face of people thinking basic income will result in a bunch of stay at home drunks
SVG is cool. Was really wanting SVG2 as in order to get wordwrap I'm embedding HTML into the SVG which I'm embedding in HTML. openEtG uses SVG as an alternate backend to cards/deck rendering (as opposed to <canvas>)
Deck SVG: http://etg.dek.im/deck/047130c6qq016u1036u30177o0177g027aq02...
Card SVG: http://etg.dek.im/card/56f.svg
There's some issues in rendering interacting with the page's CSS. The card back is rendered off a spritesheet, in the SVG I just offset it so that the rest of the image is clipped away
Code: https://github.com/serprex/openEtG/blob/master/svg.js
If this seems off topic.. well I'm bad at being personal, & in response to a personal blogpost, this is how I make a personal response
I was hoping to try get remote work with https://bocoup.com but unfortunately I'm also Canadian & they're not open to being that remote. But I'm just some guy who made an open source HTML5 CCG. Maybe they'd take closer consideration of you. Granted I open with a salary of 25k CAD, don't know what you consider making due
Sort of flies in the face of people thinking basic income will result in a bunch of stay at home drunks
SVG is cool. Was really wanting SVG2 as in order to get wordwrap I'm embedding HTML into the SVG which I'm embedding in HTML. openEtG uses SVG as an alternate backend to cards/deck rendering (as opposed to <canvas>)
Deck SVG: http://etg.dek.im/deck/047130c6qq016u1036u30177o0177g027aq02...
Card SVG: http://etg.dek.im/card/56f.svg
There's some issues in rendering interacting with the page's CSS. The card back is rendered off a spritesheet, in the SVG I just offset it so that the rest of the image is clipped away
Code: https://github.com/serprex/openEtG/blob/master/svg.js
If this seems off topic.. well I'm bad at being personal, & in response to a personal blogpost, this is how I make a personal response
I was hoping to try get remote work with https://bocoup.com but unfortunately I'm also Canadian & they're not open to being that remote. But I'm just some guy who made an open source HTML5 CCG. Maybe they'd take closer consideration of you. Granted I open with a salary of 25k CAD, don't know what you consider making due
Tell me more about your WASM lua jit.
Any feedback from my post here? https://www.freelists.org/post/luajit/LuaJIT-and-WebAssembly...
Any feedback from my post here? https://www.freelists.org/post/luajit/LuaJIT-and-WebAssembly...
https://github.com/serprex/luwa
Have a basic interpreter worked out, currently implementing tracing, no WASM currently being output. I have some previous experience generating wasm tho:
https://github.com/serprex/Befunge https://github.com/serprex/brainwebfuckassembly
I don't really care about interacting with DOM. I feel that something like vDOM & working out a method to play nice with emscripten's ABI will have more use for projects which want to run a wasm jit with the code being mostly in WASM
lua.js seems promising on the not-wasm front. Possibility to allow coroutines by implementing those on top of generators like I've done in my own implementation
Have a basic interpreter worked out, currently implementing tracing, no WASM currently being output. I have some previous experience generating wasm tho:
https://github.com/serprex/Befunge https://github.com/serprex/brainwebfuckassembly
I don't really care about interacting with DOM. I feel that something like vDOM & working out a method to play nice with emscripten's ABI will have more use for projects which want to run a wasm jit with the code being mostly in WASM
lua.js seems promising on the not-wasm front. Possibility to allow coroutines by implementing those on top of generators like I've done in my own implementation
SVG is a good example of an overflexible, overcomplex standard with too much variety, too many options, too many different ways to do the same thing. The huge flexibility makes it almost impossible to correctly and fully implement.
I'm not sure how it got this way, but it seems to be connected to the W3 consortium, which has many other instances of creating exceedingly complex, difficult-to-implement standards.
I'm not sure how it got this way, but it seems to be connected to the W3 consortium, which has many other instances of creating exceedingly complex, difficult-to-implement standards.
Part of this is that W3C standards are created separately from each other. But SVG 2 actually included a lot of work for harmonising SVG ways of doing things with CSS ways of doing things (in those cases it was often CSS doing something differently that has existed in SVG before, though). There's pretty much not a single web technology that isn't plagued by such problems, as much of it came to be as some browser experimenting, others eventually following suit, and only then being standardised.
Really? I feel like HTML & CSS have this problem way worse than SVG...
Yes, really.
> I feel like HTML & CSS have this problem way worse than SVG...
I don't want to be rude to you, but in my comment above, I wrote the following:
> I'm not sure how it got this way, but it seems to be connected to the W3 consortium, which has many other instances of creating exceedingly complex, difficult-to-implement standards.
I don't want to be rude to you or hurt your feelings, but the W3 consortium wrote the standards for HTML and CSS as well.
> I feel like HTML & CSS have this problem way worse than SVG...
I don't want to be rude to you, but in my comment above, I wrote the following:
> I'm not sure how it got this way, but it seems to be connected to the W3 consortium, which has many other instances of creating exceedingly complex, difficult-to-implement standards.
I don't want to be rude to you or hurt your feelings, but the W3 consortium wrote the standards for HTML and CSS as well.
I did read your comment. I do know that the W3C worked on all of them. I promise not take anything as rude as long as you're not trying to be rude. :) You didn't really clarify why SVG is a particularly good example, or why you're pointing a finger in the general direction of the W3C.
How much have you used SVG? If you agree that HTML & CSS are worse than SVG, then what are you suggesting should be done about SVG?
Personally, I find SVG pleasant to use compared to trying to get layout to work across different versions of browsers. Personally, I'd rather use SVG than CSS, if I have a choice. I was questioning why you think SVG is a "good" example of an overly complex API, relative to what seem like bigger & better examples.
Pretty much all standards are difficult to implement. Tiff is an example of an image standard that almost nobody gets right, and it's way smaller in scope than HTML, CSS or SVG. It's also not made by the W3C. OpenGL is a standard that is very complicated and nobody implements completely, not even nVidia. There is a constant stream of complaints about it, and yet nothing better has come along to supplant it.
Standards are standards because there are many groups of people with many different, and changing, requirements using them. That's why they get complex.
Standards are always a disaster from the point of view of bystanders & people not involved and unaware of the history of the standard. They're often a disaster from the point of view of people working on them too, but sometimes for different reasons.
In any case, the question on the table is what to do about it, that's what Amelia is asking. There's no question: things would get worse, not better, if we were to eliminate the SVG (or HTML or CSS) standards. There has to be a proposal on the table to replace it with something better.
What do you propose?
How much have you used SVG? If you agree that HTML & CSS are worse than SVG, then what are you suggesting should be done about SVG?
Personally, I find SVG pleasant to use compared to trying to get layout to work across different versions of browsers. Personally, I'd rather use SVG than CSS, if I have a choice. I was questioning why you think SVG is a "good" example of an overly complex API, relative to what seem like bigger & better examples.
Pretty much all standards are difficult to implement. Tiff is an example of an image standard that almost nobody gets right, and it's way smaller in scope than HTML, CSS or SVG. It's also not made by the W3C. OpenGL is a standard that is very complicated and nobody implements completely, not even nVidia. There is a constant stream of complaints about it, and yet nothing better has come along to supplant it.
Standards are standards because there are many groups of people with many different, and changing, requirements using them. That's why they get complex.
Standards are always a disaster from the point of view of bystanders & people not involved and unaware of the history of the standard. They're often a disaster from the point of view of people working on them too, but sometimes for different reasons.
In any case, the question on the table is what to do about it, that's what Amelia is asking. There's no question: things would get worse, not better, if we were to eliminate the SVG (or HTML or CSS) standards. There has to be a proposal on the table to replace it with something better.
What do you propose?
> Standards are standards because there are many groups of people with many different, and changing, requirements using them. That's why they get complex.
This doesn't correspond to the information I have about SVG. As far as I know, W3 consortium rejected numerous proposals for a vector graphics standard and created their own from scratch. But I was not sure of that, so I did a little online research.
I found this page linked from Wikipedia:
https://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG
> The SVG WG examined the general requirements and the various submissions, and decided to not 'develop' any of the submissions, but to develop a new language informed by, but not really based on, any of the submissions.
According to this page, they claim they invented it themselves, "not really based on" any of the submissions.
I actually do not know if the other submissions there are as much of a muddle as SVG, but I doubt it.
This doesn't correspond to the information I have about SVG. As far as I know, W3 consortium rejected numerous proposals for a vector graphics standard and created their own from scratch. But I was not sure of that, so I did a little online research.
I found this page linked from Wikipedia:
https://www.w3.org/Graphics/SVG/WG/wiki/Secret_Origin_of_SVG
> The SVG WG examined the general requirements and the various submissions, and decided to not 'develop' any of the submissions, but to develop a new language informed by, but not really based on, any of the submissions.
According to this page, they claim they invented it themselves, "not really based on" any of the submissions.
I actually do not know if the other submissions there are as much of a muddle as SVG, but I doubt it.
What's your point? That doesn't mean anything. Proposals for standards are rejected all the time by all standards committees. You don't seem to understand the reality of standards work, it is notoriously difficult.
What do you propose to do with SVG? Get rid of it? Replace it? With what?
What do you propose to do with SVG? Get rid of it? Replace it? With what?
> Proposals for standards are rejected all the time by all standards committees.
and yet
> Standards are standards because there are many groups of people with many different, and changing, requirements using them.
So on the one hand they're rejecting whatever, and on the other hand they are catering to all the different and changing requirements.
> What's your point?
I do not wish to seem rude but my point is "SVG is a good example of an overflexible, overcomplex standard with too much variety, too many options, too many different ways to do the same thing. The huge flexibility makes it almost impossible to correctly and fully implement."
and yet
> Standards are standards because there are many groups of people with many different, and changing, requirements using them.
So on the one hand they're rejecting whatever, and on the other hand they are catering to all the different and changing requirements.
> What's your point?
I do not wish to seem rude but my point is "SVG is a good example of an overflexible, overcomplex standard with too much variety, too many options, too many different ways to do the same thing. The huge flexibility makes it almost impossible to correctly and fully implement."
You don't seem rude, but you do you seem unwilling say something constructive.
Since Amelia isn't sure she wants to continue with SVG standards work, I volunteer you to go and simplify and fix the SVG standard. You've stated your opinion that it's too complex three times, so you must know what parts of it can be cleaned up?
Go do it.
Since Amelia isn't sure she wants to continue with SVG standards work, I volunteer you to go and simplify and fix the SVG standard. You've stated your opinion that it's too complex three times, so you must know what parts of it can be cleaned up?
Go do it.
How is that constructive, you are just being silly now.
For something constructive, need a suggestions for a solution, a way forward.
Pointing out problems is not the hard thing, solving or preventing the problem is.
As someone who is pushing what SVG can do in terms of interactivity and animation I am saddened to see such a hard working and talented person person like Amelia struggling like this. She has helped me on numerous occasion with various issues over the years and her knowledge of SVG and its quirks and foibles is extensive.
If anyone is questioning the relevance or flexibility of SVG or its ease of use check my CodePen stuff - with a library like Greensock you can do almost anything with SVG http://codepen.io/chrisgannon/
If anyone is questioning the relevance or flexibility of SVG or its ease of use check my CodePen stuff - with a library like Greensock you can do almost anything with SVG http://codepen.io/chrisgannon/
Don't give up. SVG is a beautiful format for the web. People can see the difference in quality.
I'm about 20 years into my career and what I would tell her is that I've become an expert in and forgotten more technologies then I can remember. But it's not a waste of time, somehow things from 20 years ago that seem like completely useless knowledge still popup once in a while and inform my decisions and make me a better engineer overall.
I have been both super excited and super disappointed with SVG for about fifteen years now. I too came into it as a dataviz practitioner. Ten years ago I did a project where I generated system status diagrams directly out of SQL Server using XSLT and SVG embedded into the engine. More recently my interest has been resurrected since Power BI uses SVG and D3 for custom visualizations. But the luke-warm browser support has always been discouraging. Same with XSLT. And I guess all things with angle brackets these days.
I don't have advice for you but I just want to say this is a stunning body of work - congratulations.
I agree and would also send a thank you to the original author for all her hard work. I use SVG semi-regularly and appreciate the work involved.
Indeed - svg allowed me to explore my artistic side (craft, carpentry etc). If the author set up a patreon, I could donate or something.
I was (aiming to become) an SVG ninja around 2006 (the first coming of SVG in the browser), coded stuff like http://web.archive.org/web/20070630201408/http://www.fragmen... ( a kinda LOGO implementation in SVG) - you needed the adobe SVG viewer plugin for IE at that time to use it. (don't look at the code, it was 2006!!!!)).
at one point I decided to stop my quest, mostly because
a) horrible buggy browser support at that time
b) the limitation and clunkiness of the format (it's XMLish after all)
so basically nowadays: same, same but different!
nowadays still use exported SVG for icons and logos of course, cause filesize.
at one point I decided to stop my quest, mostly because
a) horrible buggy browser support at that time
b) the limitation and clunkiness of the format (it's XMLish after all)
so basically nowadays: same, same but different!
nowadays still use exported SVG for icons and logos of course, cause filesize.
I suspect it is possible you would be able to monetize your SVG experience in a more profitable way than an O'Reilly book by authoring an online course(s) for vendors like Pluralsight, Frontend Masters, or similar companies?
"But I hate working with broken tools.
Do I keep trying to fix it, or do I throw it away?"
At some point, I think we need a redesign for vectorgraphics on the web from scratch, as I don't think SVG can really be "fixed" - it is just too complex and weird in the base.
But I guess no one is willing to spend much money on that right now, after the core of svg finally works (mostly). And since it is there right now and working, it won't go away so fast, as there is no alternative - yet.
So I would keep working with it, but maybe start to collect and share ideas on how to do things nicely from scratch ...
Do I keep trying to fix it, or do I throw it away?"
At some point, I think we need a redesign for vectorgraphics on the web from scratch, as I don't think SVG can really be "fixed" - it is just too complex and weird in the base.
But I guess no one is willing to spend much money on that right now, after the core of svg finally works (mostly). And since it is there right now and working, it won't go away so fast, as there is no alternative - yet.
So I would keep working with it, but maybe start to collect and share ideas on how to do things nicely from scratch ...
I disagree. This is the classic, let's rebuild it from scratch blackhole. You'd probably end up with much the same spec.
The one thing that does need to be done to svg is to work towards simplifying it and depreciating some of the more edgy features. It's a really broad spec that's complex to implement.
The one thing that does need to be done to svg is to work towards simplifying it and depreciating some of the more edgy features. It's a really broad spec that's complex to implement.
Question, have you really worked with SVG? And have you seen, how other vector graphics format are (better) implemented?
I've done quite a bit, yeah. We make serious use of it in our product [1] so I've had to work with it fairly closely on both the front and backends (have read through the Chrome svg code, along with Skia, Cairo and others). In terms of other declarative 2D formats, I'm also increasingly familiar with PDF too.
Just this last week I fixed a bug in the way Cairo handles stroke-miterlimit (which was called by librsvg). While there I got an appreciation for how exactly the rendering has to take place.
Imagine drawing a stroked line of 2 segments (on any 2D surface), it's the simplest of operations. If you think about it, that's actually an operation in which you have to draw 2 rectangles (one for each line segment) that meet at their tip centres, and then you need to draw the fill (determined by the stroke-linejoin) at the tip (after figuring out which side of the line is the outside). The options are rounded, bevel (just a triangle to fill in the space and effectively square off the join) and miter (draw a diamond to extend off to the full extent of the line). The miterlimit then specifies a maximum ratio you will allow before saying that the miter would extend too far and you'd rather have a bevel (squared off).
Cairo does these calculations in several places for the various backends, but it has code to deal with stroke-linejoins and stroke-miterlimits. PDF has the same sorts of operations, as does Skia / all other 2D libraries.
Now, SVG2 has introduced the notion of miter-clip in which you don't just have the end of the line snap to bevel or miter and instead you can have it cut off somewhere in between.
It's an innocent enough addition, but let's stop and think about the implementation. None of the drawing canvases support it, so you'd have to add it to Skia and Cairo / everything else. Just on the image backend of Cairo, that's a big change. There's a load more calculations that need to happen. But what if the user is using the PDF or Skia backend? Do you just give inconsistent results there if they don't support it, or do you try to simulate the drawing operations to plug in the little extra line-joins to make things look right. Alternatively, librsvg for example could handle it as a special case, use bevels, and add its own calculations to glue in all the extra little caps. At least then Cairo wouldn't have to change. But I've just been down in that code and there's a lot of work in those calculations — you need to track angles of all the line segments, you need to figure out where things start and stop etc. But then Inkscape would need to do something similar, as would Chrome / the Edge renderer etc.
And this is a relatively simple case. See miter-clip in the spec [2]. It's a 1 paragraph definition that results in 1,000s and 1,000s of lines of code to be changed.
Don't get me wrong, I'm not having a go at the spec and I love SVG. It's just that over the last week I've come to appreciate how complex the seemingly simple operation of drawing a line of 2 segments is! It's worth stopping to think about how much work each feature creates.
[1] http://www.countfire.com
[2] https://www.w3.org/TR/SVG2/painting.html#LineJoin
Just this last week I fixed a bug in the way Cairo handles stroke-miterlimit (which was called by librsvg). While there I got an appreciation for how exactly the rendering has to take place.
Imagine drawing a stroked line of 2 segments (on any 2D surface), it's the simplest of operations. If you think about it, that's actually an operation in which you have to draw 2 rectangles (one for each line segment) that meet at their tip centres, and then you need to draw the fill (determined by the stroke-linejoin) at the tip (after figuring out which side of the line is the outside). The options are rounded, bevel (just a triangle to fill in the space and effectively square off the join) and miter (draw a diamond to extend off to the full extent of the line). The miterlimit then specifies a maximum ratio you will allow before saying that the miter would extend too far and you'd rather have a bevel (squared off).
Cairo does these calculations in several places for the various backends, but it has code to deal with stroke-linejoins and stroke-miterlimits. PDF has the same sorts of operations, as does Skia / all other 2D libraries.
Now, SVG2 has introduced the notion of miter-clip in which you don't just have the end of the line snap to bevel or miter and instead you can have it cut off somewhere in between.
It's an innocent enough addition, but let's stop and think about the implementation. None of the drawing canvases support it, so you'd have to add it to Skia and Cairo / everything else. Just on the image backend of Cairo, that's a big change. There's a load more calculations that need to happen. But what if the user is using the PDF or Skia backend? Do you just give inconsistent results there if they don't support it, or do you try to simulate the drawing operations to plug in the little extra line-joins to make things look right. Alternatively, librsvg for example could handle it as a special case, use bevels, and add its own calculations to glue in all the extra little caps. At least then Cairo wouldn't have to change. But I've just been down in that code and there's a lot of work in those calculations — you need to track angles of all the line segments, you need to figure out where things start and stop etc. But then Inkscape would need to do something similar, as would Chrome / the Edge renderer etc.
And this is a relatively simple case. See miter-clip in the spec [2]. It's a 1 paragraph definition that results in 1,000s and 1,000s of lines of code to be changed.
Don't get me wrong, I'm not having a go at the spec and I love SVG. It's just that over the last week I've come to appreciate how complex the seemingly simple operation of drawing a line of 2 segments is! It's worth stopping to think about how much work each feature creates.
[1] http://www.countfire.com
[2] https://www.w3.org/TR/SVG2/painting.html#LineJoin
If companies have to pay the W3C and the W3C don't pays spec editors such as her; where does that money go?
The W3C does pay (some) people to work on specs, usually not on a contractual basis though, just by hiring in priority areas. For example, some of the main figures in the CSS, Web Accessibility, Web Payments, etc. groups are W3C employees. There's a list of employees and what they work on here: https://www.w3.org/People/
I've benefitted numerous times from AmeliaBB's answers on StackOverflow/StackExchange and Sitepoint, and am really happy for the opportunity to thank her very much for her work. Her authoritative answers really stand out, and show a level of depth and comittment to the subject like few others. Her book is now high an my reading list.
There's definitely something wrong with funding of web standardization work (or lack thereof) though, that needs to be brought to public attention. The WHATWG/W3C situation is unsustainable IMO.
There's definitely something wrong with funding of web standardization work (or lack thereof) though, that needs to be brought to public attention. The WHATWG/W3C situation is unsustainable IMO.
One thing that could be done by somebody who knows the standard /really/ well, is a proper SVG sanitizer/conformity enforcer. SVG is powerful, even in its basic abilities, but all of the projects I've seen so far have no guarantees of security or safe parsing. Its probably too niche currently, probably only really useful for things like Mediawiki. But, I think having the ability for users to upload .svg's like normal images onto sites would catch on pretty quick.
Why don't most programmers buy programming books? Why doesn't the technology industry have more respect for the foundational, vocational work being done that supports it?
It's the Market I hear you cry. I'm damn tired of hearing that cop out. Maybe you really believe it. Well that doesn't mean you don't have to take responsibility.
These people support our money earning work every day. We need to find ways to force our employers to put a value on that.
It's the Market I hear you cry. I'm damn tired of hearing that cop out. Maybe you really believe it. Well that doesn't mean you don't have to take responsibility.
These people support our money earning work every day. We need to find ways to force our employers to put a value on that.
It's tough. I think the appetite for SVG might have dissipated a bit since devices properly scale and use alternatives such as canvas offer better performance.
I bet a hackathon would do a ton of good for the SVG Ecosystem.
The social/community/ecosystem aspect of programming technologies should not be neglected/ignored.
The social/community/ecosystem aspect of programming technologies should not be neglected/ignored.
It's sad to hear that the author has had such a financially hard time while working on those things. But the thing is that those books are not best sellers. There are like 10 ppl in the world interested in SVG.
I'm sorry to say but also committing to a large chunks of work without any contract for payment?? I can understand that you'd do it if you really a) wanted to do it b) wanted the "fame" or the admiration of your peers but to continue to work on while the teams around you are falling apart and not giving a shit is just pointless. Maybe she wasn't able to read the state of the project very well.
Anyway author if you read this, I'd say just scrap the SVG for now and pursue other paths. You can always go back to it if interest towards SVG takes off again.
I'm sorry to say but also committing to a large chunks of work without any contract for payment?? I can understand that you'd do it if you really a) wanted to do it b) wanted the "fame" or the admiration of your peers but to continue to work on while the teams around you are falling apart and not giving a shit is just pointless. Maybe she wasn't able to read the state of the project very well.
Anyway author if you read this, I'd say just scrap the SVG for now and pursue other paths. You can always go back to it if interest towards SVG takes off again.
FXG was much nicer.
Boy howdy do I wish Adobe hadn't mismanaged Flash and Flex so badly they killed them. If they'd gone more open, fixed performance issues on non-Windows platforms, and actually followed through on the Tamarin gesture we'd all be in a happier place.
Boy howdy do I wish Adobe hadn't mismanaged Flash and Flex so badly they killed them. If they'd gone more open, fixed performance issues on non-Windows platforms, and actually followed through on the Tamarin gesture we'd all be in a happier place.
I have asked my local library to order her SVG Essentials book & they did. I have checked an people are taking it out and since then they have ordered other SVG books.
VPaint[1] is a research vector graphics editor (from SIGGRAPH 2015) that has higher-level semantics of vector graphics editting. And it claimed more efficiency to create vector graphics. May it be the hope to fix problems of SVG you guys mentioned?
[1] http://www.vpaint.org/
[1] http://www.vpaint.org/
There are at least three ways to draw in browsers now - a canvas object, WebGL, and SVG. Apparently SVG is losing out for that application.
As a common representation for draw programs, SVG is quite useful. But apparently it accumulated way too many features, and SVG 2, this author says, was an solution to a non-problem.
As a common representation for draw programs, SVG is quite useful. But apparently it accumulated way too many features, and SVG 2, this author says, was an solution to a non-problem.
They're all quite different. Canvas is raster based, SVG is vector, and WebGL is a totally different approach tailored to hardware acceleration (and still paints into a canvas, so it's raster ultimately).
For display, eventually everything is a raster, unless you output to something like a pen plotter. Canvas has primitives including 'draw line', 'draw circle', etc., and can be used as a lower level for a scene graph. There's "scenegraph.js"; unclear if it's used much.
You can use WebGL as a 2D drawing system. On machines with OpenGL hardware support (which today is everything above a flip phone) that's a reasonable way to do fast 2D work. Games often do that for their menu screens.
SVG is more useful as a storage format than as a graphics toolbox.
You can use WebGL as a 2D drawing system. On machines with OpenGL hardware support (which today is everything above a flip phone) that's a reasonable way to do fast 2D work. Games often do that for their menu screens.
SVG is more useful as a storage format than as a graphics toolbox.
Holy crap.
I've read the first 30% of the article - you are clearly the expert.
Then fast forward to the end: "if only I could figure out a way to make them pay"
Chronic fatigue (medical condition) is an issue and there should be a way to work around that...
Independent, remote work, creating infographics and visualisations for media outlets - that's a pretty large niche!
I've read the first 30% of the article - you are clearly the expert.
Then fast forward to the end: "if only I could figure out a way to make them pay"
Chronic fatigue (medical condition) is an issue and there should be a way to work around that...
Independent, remote work, creating infographics and visualisations for media outlets - that's a pretty large niche!
Thanks to the author for all their work. SVG is becoming a little more connected to some of the work I'm doing and I'm hoping a way can come up for her to be supported to continue her work if she loves it. Someone who supports a technology this selflessly a few years ahead of those who will come to need it.
[deleted]
"I am torn: I have invested this much of my life into SVG. Do I build on that? Or do I write it off and start afresh with lessons learned and no regrets?"
What product needs to built that harnesses SVG?
What product needs to built that harnesses SVG?
What product needed to be built that harnessed HTTP, when it was first created? It wasn't Google, Facebook and pets.com right away. It took a lot of time to figure that out. There is a place for foundational work, it's just hard to get funded for it.
"What product needed to be built that harnessed HTTP, when it was first created?"
Browser. '94. Killer product.
Browser. '94. Killer product.
More exactly - https://en.wikipedia.org/wiki/Netscape_Navigator
Many of the reactions in this thread are discouraging. I wonder if HN is a community worth investing in.
If you write a spec, you should also implement a proof of concept.
Did you read the post? One workgroup member was also an Inkscape developer, and was implementing the new features. Both tasks apparently fully unpaid.
And then the browser vendors come only afterwards telling that they weren't really interested in the first place.
And then the browser vendors come only afterwards telling that they weren't really interested in the first place.
I think part of what's missing here is libraries to render and convert SVG to other formats. It's no good having a feature in Inkscape which no other renderer yet implements. But if it was implemented in a library, which Inkscape and other tools could use, then it might drive adoption a bit faster.
It pains me when I create a nice SVG in inkscape, and then librsvg, QtSVG or whatever are incapable of displaying it. Better tools and libraries are needed. Running inkscape from the command-line to generate PDF, PNG and other export formats is a fallback, but it's often impractical to do that. That type of conversion should be trivial with standard tools, but isn't yet.
It pains me when I create a nice SVG in inkscape, and then librsvg, QtSVG or whatever are incapable of displaying it. Better tools and libraries are needed. Running inkscape from the command-line to generate PDF, PNG and other export formats is a fallback, but it's often impractical to do that. That type of conversion should be trivial with standard tools, but isn't yet.
I like the librsvg approach of just supporting the important features. Then again, you can't do custom fonts (which is an issue for me) and I guess everybody has features they need / would like.
librsvg can render into different backends via cairo. Maybe with a little more work the combination of them could form the library you're talking about? I definitely agree about having a good library. The way everything is deeply bound into inkscape is a real shame. And when you use something like chrome (blink) you kinda need the whole kitchen sink to make it work.
librsvg can render into different backends via cairo. Maybe with a little more work the combination of them could form the library you're talking about? I definitely agree about having a good library. The way everything is deeply bound into inkscape is a real shame. And when you use something like chrome (blink) you kinda need the whole kitchen sink to make it work.
At a guess the reason it is minimal is because there wasn't much dev work on it for a long time. If other devs had turned up and added missing features they would have been added.
Also; newer features like meshgradient haven't been in Cairo for very long.
Afaict Features get added in unescape as its open source, a soft of neutral ground + with authoring capability and artists in the community making it easy to demo proposed patches.
Also; newer features like meshgradient haven't been in Cairo for very long.
Afaict Features get added in unescape as its open source, a soft of neutral ground + with authoring capability and artists in the community making it easy to demo proposed patches.
It's a fair point though: if the kind of experience to understand/implement the spec is workgroup member + Inkscape dev, then maybe it's too complicated for mass adoption.
If compagnies have to
> But I never cared about SVG itself. It's just a tool. I cared about what I could build with it.
I'm calling BS on that last statement of hers. I don't intend for this to sound mean. I intend for it to help her (or readers), to be honest with themselves. It WOULD be sad if she wasted all this time on SVG if she really would have rather just been building stuff with SVG. However, that to me doesnt reflect reality; so it shouldn't make her sad. She got to spend time doing what she clearly actually likes doing: technical writing! Theres nothing wrong with that!
No one who actually likes to build stuff would spend so much time on committees, book deals, and technical writing. Thats okay! She should be honest with herself about her preferences.
The positives are that "committees, book deals and technical writing" are very transferable skills to whatever other web technology needs more of this sort of thing.
EDIT: I in no way mean for this to be callous regarding counting pennies. I am sympathetic to the fact that much of her work was unpaid :(
I'm calling BS on that last statement of hers. I don't intend for this to sound mean. I intend for it to help her (or readers), to be honest with themselves. It WOULD be sad if she wasted all this time on SVG if she really would have rather just been building stuff with SVG. However, that to me doesnt reflect reality; so it shouldn't make her sad. She got to spend time doing what she clearly actually likes doing: technical writing! Theres nothing wrong with that!
No one who actually likes to build stuff would spend so much time on committees, book deals, and technical writing. Thats okay! She should be honest with herself about her preferences.
The positives are that "committees, book deals and technical writing" are very transferable skills to whatever other web technology needs more of this sort of thing.
EDIT: I in no way mean for this to be callous regarding counting pennies. I am sympathetic to the fact that much of her work was unpaid :(
I'm sorry but does anyone find the following bit of code readable?
<svg class="defs-only"> <filter id="duotone" color-interpolation-filters="sRGB" x="0" y="0" height="100%" width="100%"> <feColorMatrix type="matrix" values="0.90 0 0 0 0.40 0.95 0 0 0 -0.10 -0.20 0 0 0 0.65 0 0 0 1 0" /> </filter> </svg>
SVG is a horrible way to do graphics, and not a good vector format due to its complexity. It's also difficult to get good performance, you'll eventually end up implementing stuff at a lower layer when SVG itself becomes a bottle-neck, and it has tons of cross-platform bugs that require endless debugging.
The crux of the matter is vectors are drawings, and may or may not have a hierarchical representation. It would be a lot better abstracted by a real language, using a primitive drawing API that allows you set debugger statements and the like to inspect state, variables, etc.
<svg class="defs-only"> <filter id="duotone" color-interpolation-filters="sRGB" x="0" y="0" height="100%" width="100%"> <feColorMatrix type="matrix" values="0.90 0 0 0 0.40 0.95 0 0 0 -0.10 -0.20 0 0 0 0.65 0 0 0 1 0" /> </filter> </svg>
SVG is a horrible way to do graphics, and not a good vector format due to its complexity. It's also difficult to get good performance, you'll eventually end up implementing stuff at a lower layer when SVG itself becomes a bottle-neck, and it has tons of cross-platform bugs that require endless debugging.
The crux of the matter is vectors are drawings, and may or may not have a hierarchical representation. It would be a lot better abstracted by a real language, using a primitive drawing API that allows you set debugger statements and the like to inspect state, variables, etc.
Yes, this is a pretty readable code. I don't understand it deeply, but it's clear that it's a definition that defines some filter that I can call by its id.
What seems to be a hierarchy comes from the fact that this is a serialization of the data and the serialization has to be sequential and thus you cannot have a true graph here, only a tree with references. This would be true for any serialization format. Once you deserialize this into your internal format you can have back your graph and it can be as efficient as you'd like.
As a serialization format, however, it's very good, because it's based on a good standard. What's especially good about it is that you can see through its structure and access parts of it using the same generic API as with other XML-based formats. For example, in the browser you can style SVG with the same styling you use for HTML or script it with JavaScript.
What seems to be a hierarchy comes from the fact that this is a serialization of the data and the serialization has to be sequential and thus you cannot have a true graph here, only a tree with references. This would be true for any serialization format. Once you deserialize this into your internal format you can have back your graph and it can be as efficient as you'd like.
As a serialization format, however, it's very good, because it's based on a good standard. What's especially good about it is that you can see through its structure and access parts of it using the same generic API as with other XML-based formats. For example, in the browser you can style SVG with the same styling you use for HTML or script it with JavaScript.
Ah, Turing complete imperative languages...now that's a vector image format.
With sensible indentation, and knowing nothing of SVG, the only unreadable part of that is the blob of matrix data, but I'm very glad they didn't go with something like <matrixElement row="0" column="0">0.90</matrixElement><matrixElement row="0" col="1">0</matrixElement>...
I just looked, and apparently the matrix values can contain arbitrary whitespace including newlines, so even that's not a very strong criticism. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feC...
I just looked, and apparently the matrix values can contain arbitrary whitespace including newlines, so even that's not a very strong criticism. https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feC...
Xml does not do it justice, but no way will json be any better. Creating a new format just for svg seems doomed. Whatever best suits it will have a huge battle against its adoption, especially in the browser implementations where it matters most.
Yes. I can understand that.