svg.js
svg.js copied to clipboard
Can you deconstruct/break apart a compound path?
Hey guys since you guys are 2 of the smartest SVG guys on the planet I thought I'd throw this question your way! I know SVG.js doesn't have this as a native function, but I was wondering can JS even do this? I know it probably depends on how the compound path was made - but since I can break some apart in Illustrator (unmerged I suppose?) - was wondering if you've ever had a reason to think about this one.
thanks in advance!
Here I stay as one of the 2 smartest people of this planet relating SVG (thanks for that :D) wondering what a compound path is :D. But hey I have Google :). As far as I understand this, compound paths are just multiple paths joined together. So couldn't you just search for move commands in the path and split the path where you find one? I don't imagine to be magic involved there.
Am I missing something? :D
I'll try that! Shows I use Illustrator too much :)
Not sure if I'm one of the smartest SVG guys on the planet but thanks anyway ;)
Here is a quick sketch of the concept when splitting at Z:
https://jsfiddle.net/wout/mon63ff3/
thanks Wout, I'll check that out. Well one can assume Adobe has tried to assemble the brightest SVG minds for Snap, yet SVG.js is way faster... (no offense to Dmitry!), so in my infinite wisdom I have concluded that the team behind SVG.js resides the top of the SVG world :)
Hey I upgraded to your bleeding edge stuff in the 3.0 - and it solved all of my scaling issues in an instant. Not sure if it will break anything else, but boy the scaling is sweet. It says 2.5 at the top - but I'm using the distribution file from your 3.0 repo.
Gracias - estoy super agradecida por todo esto - hope to post a link to our upcoming app soon.
You use 3.0? Wow that's not even a pre release :D. Don't wonder if the api changes and your code breaks. However I am happy that you are happy with that version. There will be a lot other changes until we will release but we are working on it :)
What I'm doing is pretty bleeding edge, so I don't mind hacking with you guys a bit :) - I was using something so old and hacked that it was just painful, and had to bite the bullet and ditch it. I'll be happy to share any problems and keep updating my code as you guys do - I'm not doing anything really fancy so that should help. Just a question - what do you guys use SVG.js with in your day jobs? It must be a cool app!
I have to admit that I do not use svg.js in my daily projects. I once worked for vizzlo - they use svg.js to draw their charts. But that was the only thing until now :).
However - we internally discussed a lot about SVG.Set and thought about removing it. In the 3.0 branch it is currently removed but we think about readding it in a more jquery way. What's your day to day experience of this? Do you use SVG.Set? And how do you use it?
BTW we opened a gitter chat for svg.js - just search for it. Would he happy to discuss there with you :)
nope not using set - probably should though. I'll look for the chat as depending what you all have going on, I may have a project that would interest you all!
@mspanish
Well one can assume Adobe has tried to assemble the brightest SVG minds for Snap, yet SVG.js is way faster... (no offense to Dmitry!), so in my infinite wisdom I have concluded that the team behind SVG.js resides the top of the SVG world :)
You have a point there :)
Just a question - what do you guys use SVG.js with in your day jobs? It must be a cool app!
Actually, I wrote SVG.js for an online web-to-print editor. At the time Raphael was the only decent thing around, but it lacked in many places. It was hard to build something reliable on top of a library that is crippled by a vintage technology like VML. Snap wasn't around yet so I decided to get my hands dirty and write SVG.js.
The web-to-print editor I built was in production between 2012 and 2017, we officially killed last month. It was a painful decision but there were many issues with text and fonts, which has proven unreliable when used cross-browser. And then there is also the issue of flowing text, which is a pain to implement and gets really slow when using a lot of text. Also, the translation from web SVG to a print-ready PDF was a struggle as well. Those issues eventually made us pull the plug.
But I use SVG.js for a lot of other projects. Lately, I'm working on a large interior project (450 m2) made in wood, where we will cut everything by CNC. It's like a gigantic 3D puzzle. Drawing all the parts by hand is a big pain. Very unreliable and impossible to make corrections to the parts afterwards without making many mistakes. So I'm writing an app (@Fuzzyma wrote a plugin for it) to generate all the cutting files dynamically. Unlike the web-to-print editor, this will all be open-sourced in the upcoming months. Both the codebase as well as the 3D puzzle.
Aside from that, there are many other small personal projects I use it for.
Thanks for the history. Once we get a little further I'll find you all on the gitter chat - we've got a pretty interesting app and may end up well funded (being an optimist, of course). One bad thing about Alaska is the lack of technical talent - but we'd love to build our team w/ part time remote folks rather than moving to Mountain View!
Quick question @mspanish, for scaling do you use the scale method?
I used to use an SVG.extend plugin - but since updating to the dev version, scale has worked for the stuff I've tried so far. I need to scale by center - and after updating it seemed to do that - but I haven't tested extensively yet - I'll let you know if I change to another method.
To ask an unrelated question - any progress on a precision setting in the 3.0? I tried hacking it and failed miserably. I'm doing a really data intensive thing right now writing paths to JSON and they are really big right now!
No progress at all I'm afraid. If you're looking for rounding in paths, check the arrayToString function in src/helpers.js. If you're after performance, try to avoid parseInt because it's very slow: https://jsperf.com/rounding-numbers-down
@mspanish To see most of what svg.js can do in an app: Oroboro Videos This is an SVG editor with a Gallery at: Oroboro Gallery
Hehe - basically everyone wants to code an svg editor :D
@Fuzzyma Oroboro editor was already done a while ago. svg.js was still at ver. 1 We are waiting for ver. 3 to refactor it with a large sum of improvements. A small part of them are also demoed in the videos above at new features and SVG UI: menu and buttons. The editor is open sourced at Oroboro Editor
@ctzurcanu very cool! My project isn't so much an editor as it is an art creation tool - I look forward to being able to use your editor, as I'm sure I'll get many good ideas! I too relied on 1.0 for a very long time, and only when I refactored my own project into a much smaller version was I able to update - I still haven't tested all of the old features against the newer version, but I'm enjoying the improved scaling very much.
Still having a hard time centering and resizing weird SVGs I've found online - I'm using a lot of open source artwork, and getting it all to resize to fit a box reliably is still difficult. My own fault, to be sure!
When breaking apart a compound path is there a way to actually subtract the inner paths versus setting them to fill:none? The fill:none option creates a layering effect which works fine in the browser (chrome) but not in Adobe Illustrator
You cannot substract a simple path from another simple path. The only way to do that is using a compound path. Thats what they are for.
You ofc can fill the second path with the backgroundcolor but thats just layering as you already pointed out
How does desktop software like illustrator handle this? For example: I created a square (path) Then I created a star (path) And used the "Minus Front" option to cut the star out of the square.
The resulting compound path doesn't require any evenodd fill rules. https://jsfiddle.net/r4crgyae/
It most likely just glues together both paths. e.g.
path1, path2
var newPath = rootSVG.path(path1.attr('d') + ' ' + path2.attr('d'))
// EDIT: @villanus this is something you can figure our by yourself. I guess you know the principles of svg so it shouldnt be that hard
@Fuzzyma I looked into this a little more and it looks like you need to reverse the data within each sub path.
http://stackoverflow.com/questions/3349651/how-to-achieve-donut-holes-with-paths-in-raphael
My javascript skills are Pathetic, so I have not been able to test it yet, but as soon as I come up with a working example I will share.
Supported by SVG.js? It might be useful for SVG.js to have a function to "Dognut" paths. Specially because Illustrator doesnt respect the EvenOdd rules. I guess the function could be used to break up compound paths with EvenOdd rule and subtract the inner parts. Not sure if this is too complicated when there are a series of paths nested within each other.
Is this worth creating a separate issue for?
Just to chime in here (old issue I know). But the requirement here is to implement the boolean operations on svg paths. To do this, we need to:
- Compute intersections between two paths (while accounting for similar areas)
- Assemble a planar graph from the intersections
- Walk around the intersections and calculate the winding number of every loop
- Keep loops that have the correct winding number for the operation
This is a reasonably difficult calculation to get right, there are implementations for:
The general algorithm is the Greiner Horman Clipping Algorithm, but we'd want to support common edges.
Just to give a usual use case for this. Imagine I have two circles, and I want to combine them into a single venn diagram and draw its outline.
Holy crap "splitting at Z" works, in my case. Thanks @wout !!!
I simply opened up the SVG in a code editor and did this:
find:
z
replace:
z"/> <path d="