SVG can do that?
slides.com
slides.com
Of course the opposite is actually a brilliant idea (at least at a time when XML was still popular): Take an XML dataset and visualise it in SVG using XSLT transformations (well... yeah... doing it all in XSLT is still insane, but you get the idea).
Anyway, we built a very high performance SVG viewer (for the time, anyway) from scratch. We built an SVG/Javascript widget library. We built an incredibly impressive data manipulation library in XSLT (ok... yeah... insane).
Fun times. And all nearly 20 years ago. It really was ahead of its time. Of course the end finally had to come. The PGMs sold this thing to a certain aviation company with the promise that it would automatically build circuit diagrams from their XML chipset database (because.... XSLT!)
When Vector took over Corel, they very rightly dropped our division like a hot potato (we had something like 3 PGMs per developer). It was quite unfortunate because the developers and QA people I worked with there were some of the best I've every had the pleasure of working with. I've always waited for something to come of SVG and really wish we had been able to release something that wasn't crazy so that people could see what the potential was.
Edit: In my old age I'm losing track of time. It seems that Vector acquired Corel in 2003, so that's only 15 years ago :-)
It's not without its wobbly bits, but show me a language that isn't.
1. It's Turing-complete, which means you can just use any other language for XML manipulation as well such as JavaScript (has DOM language bindings) or Prolog (rule/pattern based like XSLT) or maybe LISP (like DSSSL was). The benefit is that using a mainstream language gives you better mindshare and infrastructure such as APIs for DB access, IDE support for testing, etc. which I found inevitably necessary in every large XSLT project
2. XSLT 2 and 3 only has a single implementation (Saxon) by the same author as the XSLT spec itself - not my idea of a standard (and, in fact, not meeting W3C's criteria of at least two interoperable implementations).
XSLT works well if you need lots of literal XML content to be produced to the output, but will get verbose, degenerative, and awkward (priority rules) for highly dynamic content.
I don't think I agree about responsive css, but that's another discussion.
It was originally written in XSLT 1.0 so that it could generate in the web browser, which had some serious limitations and was incredibly verbose. XSLT 2 is much less verbose, but obviously XML is verbose in general.
If I had to do it over, I'd use Lisp, but the functional and template-based style of XSLT made for very natural syntax-directed translation for the compilers. I still have the cruft of old XSLT 1 code (which was written when I was also _learning_ XSLT), but all things considered, it's not all that bad. Most of the pain points are the patchwork evolution of the project; done from scratch in XSLT, it'd be much more elegant.
And, like Lisp, XSLT can parse itself as data (sans xpath). That allowed me to use a semi-literate style (generate literate documentation from the sources), for example.
[0]: https://github.com/lovullo/tame [1]: https://github.com/lovullo/liza-proguic/tree/master/src [2]: https://github.com/lovullo/literate-xsl with example output https://mikegerwitz.com/hoxsl/manual/
Product Manager - Figures out what new features or changes the product needs to better fit or find a new audience. Usually responsible for doing market research and analysis.
Business Product Owner - Similar to product manager, they own all changes associated with a company product. Position should only exist if product is so large, multiple product managers are needed for it. The product managers would then need to report to or clear their work past this individual.
Program Manager - Everyone above reports to this person. They own all of the products. And possibly oversee development as well.
XSLT is a programming language. It's not the usual kind of programming language where you tell the computer what to do. Instead it's a bit like a pattern matcher. If you have X kind of pattern, then do Y action. It's difficult to do procedural kinds of things with it, but it is awesome for transforming one kind of data to another kind of data. It reads XML files natively and you can output any kind of data you want (although usually you output XML).
We had a strange team which was heavy in "idea people". These people had the title "program manager" (or something similar). The idea was that they would have ideas and tell the programmers what to build. In practice, they had pretty crappy ideas and then we had to find a way to make them not crappy.
None of the program managers understood technology very well, but they latched on to ideas with a certain tenacity. One of these people found out that XSLT could transform XML. He also heard that SVG was written in XML. Finally, he also knew that there were many databases (at the time) that stored the data in XML. So he thought that it would be easy (in fact, automatic) to use XSLT to transform the data in an XML database to SVG.
The idea was to draw a picture using Corel Draw and save it as SVG. Then you would alter the picture using the data in the database using the magic of XSLT. Unfortunately he did not understand that XSLT was a programming language, and no amount of explanation would illuminate the situation. He was absolutely sure that if we added XSLT to our software then it would automatically alter SVG images in an intelligent way.
We had to take that idea and make a viable product. What we did was to make an IDE that allowed you to connect portions of an SVG diagram to data in a database. You used snippets of XSLT to transform the data in the database to transformations in the SVG diagram. On top of that, we built a GUI API that would give you a full interactive experiences using SVG rather than HTML (so you could build entire apps in SVG and hook it up to live data in a database). It was actually pretty awesome (and I take no credit for that -- we had awesome people on the team).
Unfortunately the "magic pixie dust" of XSLT was do heady a draw for the program managers and they got it into their head that you could automatically route circuit board diagrams if you had an XML database of electronic parts. This was a terminal mistake (and we warned them many, many, many times that it was impossible).
At the time of the takeover (Corel was bought by a venture capital company called Vector), we were treading water and trying not to drown. They mercifully terminated us, but unfortunately buried a pretty wonderful suite of software.
Hope that was more understandable/informative!
To be useful as a vector image format, there should be strict rules (and less cruft). Why is there no libsvg like libjpeg or libpng? Why have interaction as part of an image format?
SVG lives in an uncanny valley between jpeg and flash/js.
I think there is still a big need for a real vector interchange and display format. Right now people pick a "good" subset of SVG. Or even fallback to fonts.
My dream vector format:
- Pixel perfect across implementations at 50%,100%,200% renderings. At least grid aligned lines.
- Lossless roundtrip across apps. Start in Illustrator, edit parts in Inkscape, other parts in Animate, untouched things stay exactly the same.
- Standard zero dependency C reference implementation: Stream in, bitmap out.
Use a library (or at least a validator) that works exactly on this subset, and fails for anything not strictly conforming to this.
Of course, this is not as satisfying as a "clean slate" approach, but on the other hand, this is a clear migration path with backwards compatibility - which is always good to have during a transition period to avoid all those bootstrapping and chicken-egg issues.
https://github.com/GNOME/librsvg
However, admittedly, I use it in combination with a full blown browser because it doesn't need/handle text completely. I like SVG, but I too have accepted that if I want stuff to render properly, the only place to find a usable and complete SVG engine is in a web browser.
nanosvg is pretty good:
https://github.com/ajstarks/svgo https://speakerdeck.com/ajstarks/svgo-code-plus-picture-exam...
And even so, it still has no hairline. All line widths are finite and change when zooming.
It's implemented as vector-effect: vector-effect="non-scaling-stroke"
There's an example here https://gist.github.com/lightjs/5372867
https://www.w3.org/TR/SVGTiny12/styling.html https://www.w3.org/TR/SVGTiny12/script.html
This means it is inevitable that SVG should be Turing-complete.
and that ignoring browser specific issues, for example svg and css filtering don't work on edge/ie11
but nice hacks I guess. the real takeaway are probably svg animations, those can make cool stuff without the keyframe weirdness.
What about as part of a text format? Would anyone find that useful?
does it? Any examples of responsive grid system on SVG? What would be interesting.
SVG can't be, shouldn't be and never will be the replacement for HTML/CSS/JS.
Shameless plug, one of my first experiments with SVG+react (+cljs): https://polymeris.github.io/carlos/ Done in one day, without knowing the tech.
The "double corded" style paints one side of a cord red and the other blue. The problem comes when the pattern changes what side is which. You can play around with it to see - put in some breakpoints and you'll see the "sides" switch on some cells. This can't be done with tiles.
The tile manipulation is actually no simpler than drawing SVG, because the hard bit is calculating the entry and exit points for each tertiary cell. And SVG produces better results :)
I also plan on doing some more stuff with it someday - like deforming the grid by moving the corners. This is pretty simple with SVG but would be really hard with tiles.
For anybody interested in some example code mixing React and SVG the PipelineGraph component is here: https://github.com/jenkinsci/blueocean-plugin/blob/master/je...
It’s basically the best of every world for us (visuals, code, etc) and we’re trying to convert as much as we can to this (takes a while... we have a LOT of logos for example)
I agree, but ironically am one of the few here with a use-case that seems to be in the canvas-is-always-better category, and performance reasons aren't even the only motivation (although that matters too).
I'm working on a data browser of huge data sets, and the plotted data needs to maximise the use of the limited available pixels to convey as much information as possible (see [0] for an example). At that point canvas is the more convenient option.
[core.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/c... and [svg.cljs] https://github.com/polymeris/carlos/blob/master/src/carlos/s...
Look clear enough for me to follow. Thank you.
Will work on this, too:
(:require [carlos.core :as core]))
But I could also say these were minor quibbles.
ImageTracer is a simple raster image tracer and vectorizer that outputs SVG, 100% free, Public Domain.
Available in JavaScript (works both in the browser and with Node.js), "desktop" Java and "Android" Java:
https://github.com/jankovicsandras/imagetracerjs
Inkscape calls Potrace, but you can you use Potrace directly from the command line, too.
It's still here! It's now branded Animate CC[1], and (naturally) focuses on other output formats.
The product itself can export to SVG (https://helpx.adobe.com/animate/how-to/export-image-svg.html), but I get the impression that's only for individual frames.
Edit: https://blogs.adobe.com/creativecloud/export-svg-animations-... exports SVG animations, but only, it seems, for special types of documents ("From here you simply create a new “Snap.svg Animator” document type and begin creating content s you would normally. Publishing your content then generates a boilerplate HTML file along with all the assets you need, giving you an example of how to embed your animation into a webpage.")
For previous projects, I've had workflows where images were extracted from one place, added into existing SVG files and Inkscape was scripted to slice up and export sections into PNG files. I can't see a way to do anything similar with Affinity Designer.
Also what does "ml" mean?
SVG hits a performance ceiling as number of elements increases. Canvas, since it's rasterized image can handle a rasterized representation of millions of SVG elements.
However as Canvas dimension increase, it will hit a performance ceiling.
For example, try drawing hundreds of coloured rectangles per frame. Easy, right? If you're using WebGL, or any sensible graphics API, yes. If you're using canvas, the web-browser will parse and re-parse your colour expression CSS n times per frame. Enjoy your 100% CPU usage.
Well you can generate your imagery programmatically and then render it to canvas as a raster image. Canvas is not purely for implementing a web based drawing app.
Rasterizing expensive operations before drawing to screen is usually job one of a rendering pipeline
Rasterising ahead-of-time is all well and good, but it's not something you should have to employ just to draw simple polygons.
Basically, canvas performance depends a lot on how many pixels you draw and how you draw them (blitting an image vs. drawing a gradient are very different things, obviously).
SVG performance depends on how many things in the DOM are changed at the same time (and then it's mostly dependent on how well the browser can avoid redraws – that's an area where we frequently encounter bugs when either too much or too little is redrawn). A large static image¹ manipulated only via affine transforms performs quite well; an image containing lots of different things that all vary constantly is bad. But as long as the viewport isn't too large, canvas can be a viable alternative to SVG if the visualization is simple.
¹ Unless written like this one: https://upload.wikimedia.org/wikipedia/commons/4/4e/Sierpins...
This comes up on each SVG thread and I post the same comment each time (so excuse me if you've heard this from me before).
We render SVG that contain beyond 100k nodes in the browser and find that it works fine. You need to be careful with your manipulations and we've developed a couple of tricks to keep things snappy, but the final experience is great.
Here's a demo of it in action with a smaller SVG
We only use chrome because Firefox struggled in the initial testing. Having said that, I haven't tried in anything other than chrome in ages and I'd wager the situation has changed a lot in the last couple of years.
That's one of the issue i have with SVG browser implementation varies so much. Our product that is performant in Chrome sucks in IE11
What's the slow bit in IE? Is it the svgs?
Here's an example with over 150k nodes [1]. To be honest, we would normally doctor documents that had this many nodes to make the experience smoother for users. You'll notice that it's a bit sluggish when you zoom in and out, but panning is the same speed regardless of number of elements, and updating elements within the document is fast too.
[1] https://www.dropbox.com/s/xf89s2txvp9jb3k/Big%20SVG%20%28150...
- loading bar until website is fully loaded
- animated buttons that bounce and flash
- full screen 2 second transitions from page to page
- all in one page, no urls!
feels like 2010 again : ]
They will if more people use it.
SVG in Chrome can be particularly painful due to their mediocre support of some things (sometimes outright contradicting the spec).
That’s a vendor issue tho, nothing intrinsic to the format.
Or advanced CSS.
HTML plus 11 images in just 26KB.
Did it in about 900 bytes.
All the kb saving are meaningless with performance issues caused by lots of nodes, gradients, etc.
It's great for responsive icons, but for a full interactive UI with illustrations bitmaps are the better choice IMO unless you really need dynamic scaling.
Just because you can do it doesn't mean you should.
I recently had to convert an entire UI from SVG icons to fonts + bitmaps because the performance had gone down the drain, with just a few dozen different icons.
Here's a good Hackaday article on converting SVG to PCB file formats: http://hackaday.com/2016/01/28/beautiful-and-bizarre-boards/ PCBModE is one package I tried for a while: http://pcbmode.com/ Boldport uses this toolchain to make beautiful PCBs relying heavily on SVG: https://www.boldport.com/
I had a hard time with all these packages, however, and ended up just hacking it together by hand with python code and outputting in KiCAD format. I wasn't even able to get KiCAD to read/render it properly (too many weird elements), but since OSH Park (where I got my PCBs from) takes KiCAD format directly and gives you a preview, that all worked fine, and when I ordered my PCBs, they arrived in working condition just fine the first time.
So yeah, SVG can do a lot, including make funky PCBs.
The easiest way is to design the coil as a part, but you can use traces and arcs and stuff like normal in that.
I think I used OpenSCAD to export to SVG.
They also tend to break non-static SVG things all the time which further suggests that things like applications or animations built with SVG are definitely not a use case they cater for (or that those things are simply very rare on the top 500 sites they test).
I have in mind all those concerts or various events' png/jpeg files that are dropped on the web here and there. If they were svg files, it would be made easier for search engines to index their content.
Even without that, svg totally rocks. About a decade ago, I played with SVGWeb and made a showcase carousel presenting screenshots of projets with automated reflection on them (like it was common back then, a reverse image on bottom of actual image with a gradient from transparency to white to make an effect like if the ground was a mirror). I just had to upload a plain screenshot and everything was automated, I was mind blown, and surprised we seemed to go the canvas way instead (not so much, in retrospect).
Nowadays, I often make my icons as svg react components. It makes it so much easier to change their color or saturation on hover, this is very cool. We probably still have a long way to go to exploit all of svg potential.
The transparent JPEG-in-SVG files can also be made with nothing but ImageMagick and Bash [3].
cacheAsBitmap brought a major performance boost to Flash when used wisely though. Maybe some libraries can handle this for you nowadays?
Unless I misread it?
Totally agree with you!
Have you ever looked at a text dump of a PDF?
Assuming it's a text-PDF in the first place, there's no guarantee that it's in any sensible order.
Of course, most Web writing is pastiche anyway.
Some gotchas:
1. SVG has all these seemingly useful features that have non-obvious gotchas. Example: you can give rendering hints for svg or any child shape nodes, like "crispEdges" so that straight lines are aligned to the pixel grid (plus it might turn off anti-aliasing, but that's another matter). Great-- I've got boxes with 1-pixel borders that should always be pixel aligned to look sharp, so I choose that.
Then I notice that when I drag one of my "crispEdges" boxes to the right with the mouse, I get this weird flickering due to the "crisping" algorithm aliasing the sides of the box to the pixel grid in a way that changes the width of the visible box. (I.e., if I move the box 1 pixel to the right, the left side might align to the grid that is greater than xpos, while the right side might choose the grid that is floor(xpos).) As a result it looks like the box is "crawling" across the screen, or up the screen if you drag it vertically.
So I went back to manually aligning those boxes to the pixel grid to guarantee consistent box size.
2. The "paint server" concept is an over-engineered mess. It's incompatible with CSS gradient spec which makes it a pain to figure out how to make CSS and future of SVG play well. Sane frameworks like Snap.svg abstract away that and anything else you'd likely find inside <defs> tags. (Also, someone here on HN mentioned that <defs> junk depends on the id to reference content, which easily creates nameclashes if you use multiple inline svgs.)
3. There's some churn in the DOM interface for SVG-related utils. For example, at some point I wanted to get access to normalized path instructions for a given SVG path. But Chrome recently deprecated the old way of doing that and is in the midst of replacing it with a new geometry interface.
4. The syntax for specifying an arc inside an SVG path is weird. Like, so weird that code in an SVG library I read obviously just went straight through the instructions listed in F.6.4/F.6.5 of the SVG spec (using the exact same variable names) to simply hand off the values to Cairo, and the library still had a bug somewhere. That one isn't really a big deal-- I'm just fascinated by how the spec writers favored endpoint parameterization consistency over the user's ability to draw a pie chart without having to ask questions on StackOverflow.
5. The complexity of the spec and its interaction with the other HTML5 specs is obviously a pain point for browser devs. Sometimes I use devTools to make a quick-and-dirty realtime codepen inside about:blank which just parses a contentEditable div and injects it as innerHTML of an SVG. It's nice because you can prototype things with patterns and gradients quite easily this way. Except you can't reference gradients/patterns/etc. in Firefox this way because of god-knows-what-conflict between about:blank's baseURL and SVG's funcIRI. (Although you can base64-encode the data and inject it as the src of an img under Firefox.)
You see things like that all over. For example, the burgeoning web animations API looks really nice and works with SVG. But it works on CSS properties and not SVG attributes.
Would the same be true for SVG ? Would it be used mostly for ads, too ? Or even, can you selectively block only the SVG used for advertisments ?
It really is an amazing graphical tool. David Dailey has been posting some amazing stuff on Ello: https://ello.co/ddailey
(Which also uses SVG for most of its icons and buttons.)
But ... the potential for advertising/marketing abuse (or just sheer bad design / misuse) is so high. Unless there's a way to quash it....
Sigh. This is why we can't have nice things.