Let svg paths "intersect" - svg
sorry, but i don't know how to formulate this question ;)
I have a svg animation of an atom. (Not from me, just as an example)
http://codepen.io/davidsneighbour/pen/raPBRO
The three ellipsae (?) defined by path.class='atom-1' to 'atom-3' are at the moment on top of each other.
<path class="atom-1" fill="none" stroke="#555" stroke-width="8" stroke-miterlimit="10" d="M231.7,200c0,17.4-1.7,88-31.7,88s-31.7-70.6-31.7-88s1.7-88,31.7-88S231.7,182.6,231.7,200z"/>
I would like to create an effect of 3-d-intersection so that each ellipsis is going at least once behind one of the other ellipsae, well, as if they are intertwined in 3d.
is this possible? how do I define some kind of z-index for parts of svg paths?
Related
I need a better way to draw letters using SVG path
I am trying to convert my website logo into SVG paths. I have been doing this for 2 days, I have read every article or tutorial to use SVG but I haven't seen one that tells you how to create a simple letter. Please, I am racking my brains here. here is what I have: <path fill="none" stroke="#ff0000" stroke-width="7" d="M36 40,32,33 C-4,24 -1,98 37,54 l0,-5 -21,0"></path> And this is what I want to achieve. can you please help me how can I achieve this kind of lettering using SVG paths. As you can see, my artwork is not even close. I'm desperate.
Alright I've done it! I used adobe illustrator to export the SVG with path! and here is my end result! <svg width="114" height="17"><path fill="#ff0000" stroke="#ff0000" stroke-width="0.2" d="M12,2.08a6.39,6.39,0,0,1,2.33,3.7H11.83a4.18,4.18,0,0,0-1.6-2A4.54,4.54,0,0,0,7.61,3a4.71,4.71,0,0,0-2.5.68A4.62,4.62,0,0,0,3.39,5.65a6.42,6.42,0,0,0-.62,2.93,6.76,6.76,0,0,0,.63,3,4.42,4.42,0,0,0,1.78,1.94,5.13,5.13,0,0,0,2.66.67A4.6,4.6,0,0,0,11,13a5.17,5.17,0,0,0,1.61-3.28H7.17V7.92h7.48v2.39a7.62,7.62,0,0,1-1.17,3.1,6.8,6.8,0,0,1-2.42,2.22,7.1,7.1,0,0,1-3.45.83,7.25,7.25,0,0,1-3.83-1,6.82,6.82,0,0,1-2.57-2.8A8.82,8.82,0,0,1,.3,8.58,8.82,8.82,0,0,1,1.21,4.5,6.62,6.62,0,0,1,3.77,1.72a7.19,7.19,0,0,1,3.82-1A7,7,0,0,1,12,2.08Zm9.14,2.66a4.64,4.64,0,0,1,2.53-.69V6.76H23a3.86,3.86,0,0,0-2.54.8,3.26,3.26,0,0,0-1,2.64v6.11h-2.4V4.25h2.4V6.61A4.63,4.63,0,0,1,21.16,4.74Zm11.67.16a4.33,4.33,0,0,1,1.58,2.15V4.25h2.4V16.31h-2.4v-2.8a4.3,4.3,0,0,1-1.58,2.14,4.45,4.45,0,0,1-2.69.81,4.88,4.88,0,0,1-4.58-2.89,7.5,7.5,0,0,1-.67-3.3A7.52,7.52,0,0,1,25.56,7a4.92,4.92,0,0,1,4.58-2.89A4.45,4.45,0,0,1,32.83,4.9ZM28.31,7.34a4.22,4.22,0,0,0-1,2.93,4.2,4.2,0,0,0,1,2.92,3.28,3.28,0,0,0,2.56,1.06,3.34,3.34,0,0,0,1.81-.49A3.42,3.42,0,0,0,34,12.37a4.51,4.51,0,0,0,.46-2.1A4.5,4.5,0,0,0,34,8.18a3.34,3.34,0,0,0-3.08-1.9A3.32,3.32,0,0,0,28.31,7.34ZM49.44,5.41a5.6,5.6,0,0,1,1.22,3.87v7h-2.4V9.54A3.56,3.56,0,0,0,47.45,7a2.8,2.8,0,0,0-2.19-.89A3,3,0,0,0,43,7.1a4,4,0,0,0-.87,2.79v6.42H39.7V4.25h2.4V6.9a4.05,4.05,0,0,1,1.56-2.11,4.45,4.45,0,0,1,2.53-.74A4.16,4.16,0,0,1,49.44,5.41ZM60.81,4.9a4.18,4.18,0,0,1,1.56,2.15V.11H64.8v16.2H62.37v-2.8a4.15,4.15,0,0,1-1.56,2.14,4.45,4.45,0,0,1-2.69.81,4.88,4.88,0,0,1-4.58-2.89,7.5,7.5,0,0,1-.67-3.3A7.52,7.52,0,0,1,53.54,7a4.92,4.92,0,0,1,4.58-2.89A4.45,4.45,0,0,1,60.81,4.9ZM56.29,7.34a4.22,4.22,0,0,0-1,2.93,4.2,4.2,0,0,0,1,2.92,3.28,3.28,0,0,0,2.56,1.06,3.4,3.4,0,0,0,1.82-.49,3.47,3.47,0,0,0,1.26-1.39,4.51,4.51,0,0,0,.46-2.1,4.5,4.5,0,0,0-.46-2.09,3.31,3.31,0,0,0-3.08-1.9A3.32,3.32,0,0,0,56.29,7.34ZM84,4.25,80.72,16.31H78.07L75.2,7l-2.9,9.33H69.66L66.44,4.25h2.42L71.07,14,74,4.25h2.53L79.46,14l2.21-9.76Zm12.34,6.52H87.36a3.87,3.87,0,0,0,1,2.76,3.18,3.18,0,0,0,2.3.9,3.26,3.26,0,0,0,2-.64,2.57,2.57,0,0,0,1-1.68h2.57a5.17,5.17,0,0,1-1,2.25,5,5,0,0,1-1.91,1.54,6.43,6.43,0,0,1-5.62-.18,5.21,5.21,0,0,1-2-2.15,7,7,0,0,1-.74-3.3A7,7,0,0,1,85.74,7a5.18,5.18,0,0,1,2-2.14,6.35,6.35,0,0,1,6,0,5,5,0,0,1,2,2,5.93,5.93,0,0,1,.69,2.86A5.63,5.63,0,0,1,96.29,10.77ZM93.57,7.65a2.8,2.8,0,0,0-1.18-1.18,3.51,3.51,0,0,0-1.64-.39,3.31,3.31,0,0,0-2.36.9,3.77,3.77,0,0,0-1,2.65H94A4,4,0,0,0,93.57,7.65Zm14.49-2.81A5,5,0,0,1,109.93,7a7.52,7.52,0,0,1,.67,3.29,7.5,7.5,0,0,1-.67,3.3,4.88,4.88,0,0,1-4.57,2.89,4.46,4.46,0,0,1-2.7-.81,4.15,4.15,0,0,1-1.56-2.14v2.8H98.7V.11h2.4V7.05a4.18,4.18,0,0,1,1.56-2.15,4.46,4.46,0,0,1,2.7-.81A4.94,4.94,0,0,1,108.06,4.84Zm-5.25,1.93a3.42,3.42,0,0,0-1.27,1.41,4.5,4.5,0,0,0-.46,2.09,4.51,4.51,0,0,0,.46,2.1,3.42,3.42,0,0,0,1.27,1.39,3.34,3.34,0,0,0,1.81.49,3.31,3.31,0,0,0,2.57-1.06,4.2,4.2,0,0,0,1-2.92,4.23,4.23,0,0,0-1-2.92,3.31,3.31,0,0,0-2.57-1.07A3.43,3.43,0,0,0,102.81,6.77Z"/></svg> Beautiful!
Space between SVG stroke and fill
Filling and stroking a circle with the same color and a stroke-width exceeding a certain size, produces a strange transparent region “between” the two paint regions. What is going on? This is happening in both Chrome and Firefox, so it may be to spec, but I couldn’t find any language in the spec about this behavior. Fiddle <svg viewBox="0 0 300 300"> <circle cx="100" cy="100" r="8" stroke="#000" stroke-width="40" fill="#000"/> </svg> Produces this rendering:
As Robert Longson noted, the issue shows up when a stroke overlaps itself in such a way that it creates a donut-hole when you convert the stroke outline to a separate path (depending on the winding-order / fill-rule calculations). The gap between the fill and stroke in your particular example is caused by the "inside" edge of the stroke extending across the entire fill region and out the other side. It gets really weird when you have dashed strokes, as shown in the examples from Tavmjong Bah's discussion article. This is, unfortunately, neither according to the SVG spec nor against the spec. Instead, the spec at this point of time has left the matter undefined. SVG working group discussion is here. At this point, WebKit, Blink, and Firefox on Mac/Android draw strokes with cut-outs, using the Skia graphics library or Apple's CoreGraphics. IE/Edge and Firefox on Windows/Linux just draw the total stroke, without cut-outs, as do Inkscape and Illustrator and most PDF-rendering software (the PDF spec itself is non-committal). Everyone I've discussed this with agrees that the cut-outs are a sub-optimal result. But with so many browsers using rendering engines that do it this way, the SVG working group wasn't willing to make the more-intuitive stroke behavior a strict requirement. So instead, the SVG 2 spec has a warning-to-authors with a sample figure: At this point, the best prospect for making a change would be to file issues (or contribute code) on the Skia library. If it was changed, that puts pressure on Apple to update to match, and the SVG spec would be able to make it official.
I found that adding stroke-linecap="round" style="stroke-dasharray: 1000" fixes the issue by introducing virtual dashes <svg viewBox="0 0 300 300"> <circle cx="100" cy="100" r="8" stroke="#000" stroke-width="40" fill="#0F0" stroke-linecap="round" style="stroke-dasharray: 1000" /> </svg>
It's an artifact because the stroke width is so big it crosses the centre of the circle. It shouldn't happen but it's easily avoided by increasing r and decreasing the stroke-width.
get actual height of svg bezier curved path
This is more of a bezier question than an SVG question, but here goes... given the following code: <svg xmlns="http://www.w3.org/2000/svg" baseProfile="full" viewBox="0 0 400 400" baseProfile="full"> <path d="M0,0 C20,400 30,200 50,100" fill="#FF0000" stroke="#000000"/> </svg> Using [path].getBBox() returns me a height of 400, since the 1st control point of the curve is at 400 y, and this makes sense(ish). But what I really need is the actual height of the object as rendered, not the box that contains all points used in its drawing. I'm assuming I'm just going to have to figure it out myself? And if that's the case, does anybody have any suggestions for where to go to find such mathy things? I did some googling, but I'm not really coming up with anything (it's very possible I'm not phrasing the question correctly, some help in that regard would be super nice as well).
You are doing it right, it's a WebKit bug. If you try getBBox on Firefox or even Internet Explorer, it's fine. If you need a workaround, give a look at the implementation done for SVG-edit.
Space between hexagons in SVG
I've tried to make some hexagon-based map in SVG. Unfortunately, there are white spaces between fields. I've disabled fields' borders (stroke="none stroke-width="0"), rounded all floating points to integers and made sure that hexagons have common points (no space between them). It didn't help. Two screenshots shows same SVG in different magnifications http://imgur.com/GLiJs,gi3pt Source code is here: http://pastebin.com/hqwTKW4M (remember to change extension to svg, after download).
Setting shape-rendering property to 'crispEdges' for all hexagons (or group of them) solves this issue. E.g. <polygon points="0,90 45,12 135,12 180,90 135,168 45,168" fill="green" stroke="none" stroke-width="0" shape-rendering="crispEdges" /> http://www.w3.org/TR/SVG/painting.html#ShapeRenderingProperty
Using a clipping path with a positioned object in Webkit
Consider this simple SVG file: <svg xmlns="http://www.w3.org/2000/svg" xmlns:x="http://www.w3.org/1999/xlink" viewBox="0 0 353 150"> <defs> <clipPath id="walk0"><rect width="44" height="70" /></clipPath> <image id="img" x:href="http://phrogz.net/tmp/walking-girl2.png" width="353" height="70" /> </defs> <use x:href="#img" clip-path="url(#walk0)" /> <use x:href="#img" y="80" clip-path="url(#walk0)" /> </svg> The intent is to have two copies of the spritesheet clipped to the same region, with the second copy 80 units lower down. This works as intended in Firefox (the clipping path is applied before the y offset). In Chrome and Safari, however, the second image is not shown. (The clipping path is applied using global SVG unit space, and hence shows an empty area of the image.) 1) Which one of these browsers is correct?, or 2) What is the simplest, standards-based way to achieve this goal? I can work around the problem by using wrapping <g> elements with transforms; this works in both Firefox and Chrome. But I'm hoping that there's a simpler way to achieve the same results in a correct and cross-browser manner. FWIW, I also tried setting clipPathUnits="objectBoundingBox" on the clipPath, but this always produced an unclipped image. This was true even when I wrapped the <image> in a <symbol> with an explicit viewBox, height and width and referenced that with the <use> instead of the <image>. Either I don't understand how objectBoundingBox is supposed to work, or support for it is currently broken. It is certainly possible that the answer is the former instead of the latter. ;)
The easiest, standards-compliant way to differentiate between these is to use the SVG test suite provided by W3.org. This suite provides tests for use structs that you can play with to determine compliance, among many others. The problem is how your y value is being parsed, which is causing your figure to translate out of the second frame, but only in some browsers. This is the correct, cross-browser way to specify the desired translation: <use x:href="#img" clip-path="url(#walk0)"transform="translate(0,80)"/> I would assume the dubious parsing with respect to the current clipping pane is a regression.