Another question about SVG style transitions... :)
This time I'm trying to transition the font-size on a text element. It works fine until I increase the page zoom in Chrome. Once I do that it appears that at the start of the transition it sets the size down to the original zoom size before transitioning to the correct outcome size. The result is that I see the font-size flick smaller for a split second before growing larger.
With the default zoom the transition looks smooth. Other browsers don't seem to have this issue.
Wondering if I can try my luck again with some style-setting trick that will work more reliably across browsers...
This is happening because D3's style transitions use getComputedStyle to retrieve the starting value to be interpolated. See here for more information. When WebKit's full-page zoom is being used, this will return different starting values for the transition. This disparity is limited to certain cases including font-size, which is why you probably won't see it elsewhere.
In fact, after .style("font-size", A), retrieving via .style("font-size") isn't guaranteed to return the value A that was set when a full-page zoom is in use.
I have used the following workaround for this in the past:
.styleTween("font-size", function(d) {
return d3.interpolate(
this.style.getPropertyValue("font-size"),
d.size + "px"
);
});
This overrides D3's use of getComputedStyle and retrieves the current font-size style directly (and assumes there is a font-size already set e.g. in your .enter() selection).
Again, my word cloud experience came in handy. :)
Browser page zoom is buggy in conjunction with SVG. You can fix the zoom level with CSS, with something like * { zoom: 1; }, but that causes other inconveniences for users. You could attempt to workaround the bug in JavaScript, but I think that would be a lot of work.
Related
Is there a nice and easy way to to have the functionality of lengthAdjust (together with textLength) for shrinking text if necessary (if too wide) but never attempting to stretch it?
Two possible solutions for a SVG generated through JS come to my mind:
Count characters (or rather grapheme clusters) and based on that (together with some heuristics unless a fixed-width size font is used) determine whether to set textLength or not.
First do it without textLength set and then determine using getBBox() whether the text needs some shrinking in which case textLength will be set.
Both solutions are IMHO quite ugly (and possibly buggy from my recollections of past encounters with getBBox()). Is there maybe some nicer solution I missed?
Have a look at this: https://stackoverflow.com/a/39886640/1925631
Essentially, make a path which spans the exact coordinates where you want to spread your text on a path. Measure this path. Then, measure how many pixels your text requires, with a font-size of 1px (and other desired font-features). Now adjust the font-size to fill your desired percentage of the available path advance width. Adjust start-offset and text-anchor. Now finally calculate your author specified textLength and choose a lengthAdjust value to get exact alignment on low precision / non-conformant renderers.
Finally, if you need to support viewers without text on a path rendering support, you can use a conformant viewer with javascript support to create a backwards compatible/fallback version. Render the content and use the SVG DOM api to fetch the x, y and rotate values for each character/glyph, now create a new SVG DOM representation with those attributes specified. You might need javascript to calculate absolute width and height for the root svg element as well, and a correctly specified viewBox, and cascade/resolve/convert all css selectors/rules/properties to inline attributes. But this way you can get cross-platform, cross-browser/viewer rendering of text, with a single compilation step per immutable source file version.
I've also made a gist to ease the last step, of resolving the css and removing all classNames, while preserving the rendered end-result: https://gist.github.com/msand/4b37d3ce04246f83cb28fdbfe4716ecc
This is for the purpose of a single universal svg + javascript codebase, and web+ios+android software development (based on react + react-native + react-native-svg)
I've an svg dynamically created on a page. As things "happen" (user clicks) the svg expands and collapses certain elements. It may fit in the viewport, it may not. In the case that its too big to fit on a page, the user must scroll to where s(he) wants to go/see. Now this is fine, however I have a requirement that the last element "selected" becomes the center of the page/viewport. i.e. If they click on an item, thats what they need to see without scrolling.
Could anybody tell me the best way to attack this. I've googled around but can't find what I'm looking for (though I'm not long at all this so I might have been searching the wrong stuff).
Is there a way to do this purely programmatically with javascript? Or am I obliged to pass by CSS to get the solution I want. Any tips/links/advice much appreciated.
thanks and have a nice day
G
I had a similar thing and I used the viewBox property to handle this. You could also use a wrapping <g> element, which you translate. However, from my point of view the basic approach is the same and you basically need to do two things:
keep track of the x and y offset and the dimensions of the viewport. (Using the viewBox will give you that »for free«)
Compute the center of the Element. Therefore I used the getBoundingClientRect()method which yields the AABB of of the Element in absolute coordinate space, relative to top-left edge of the whole page.
With these things, all that remains is to calculate the vector from the viewport center to the object's center.
Here you can find the reference of the viewBox and here a nice tutorial about it, because it can be a bit confusing at the beginning.
Another pro for the »viewBox« approach is: There is no dependency on special DOM elements, it just works on the root <svg> element. I once implemented both methods, I started out using a wrapping <g> element, what worked fine but gave me some performance issues. So I decided to change and use the viewBox, with the result, that the performance in Firefox grow, but slowed down in Chromium.
Edit
Here you can find a little fiddle, that outlines the approach. But be aware of the following: getBoundingClientRect() yields the position of the Element on the whole Page, so if your <svg> is not positioned at (0,0) (top: 0px; left: 0px), than that will include the offset of the svg itself. The offset of the viewBox must not include this offset, so you need to cancel that out somehow. For sake of simplicity I just used the client Bounding Rect of the SVG, what works because there are no transformations applied.
There are three basic ways to move a path in Raphael.
If that path has a fill image that has PNG transparency, and you need IE8 (VML), all three are flawed.
JSBin demo
If you use a simple transform...
path1.animate({transform: 't20,100'},1000);
...then in IE8, the png transparency in the fill breaks and translucent pixels turn black. Edges become pixelated and ugly, and depending on the image you might get a scuffy black outline around the translucent edge of the image. Not good, and there doesn't seem to be any reliable way to fix this after the event.
Sometimes, inconsistently, the background image also doesn't stay relative to the element (more on that below).
If you animate the path attribute, for example like this:
path2.animate({path: Raphael.transformPath( path2.attr('path'), 't100,20') },1000);
...IE8 doesn't wreck the image background. However, the fix for making background images relative to the element not the paper does not work with this method (and various ways I've tried to bodge it using improved background image offset with an additional "M-20,-20" element don't seem to work), and I can't find any way to make that work either.
Also, just having lots of transformations on the go can break the delicate IE8 bug the background image fix depends on in VML mode, causing the background to move. This seems to be inconsistent - with the JSBin above, in IE8, sometimes they all move, sometimes only the top one moves.
If you use translate...
path3.translate(42,42);
...the results are the same as transform (presumably both use the same translate functions).
With Raphael image elements, it's possible to fix this broken alpha by applying opacity with the transform in an attr or animate call. This doesn't work with path fills. Also, turning off the fill and resetting it from the original URL string doesn't remove the broken alpha contamination. You can see this in this demo.
So, I'm looking for a way to move a Raphael path that has a background image that has PNG transparency that a) keeps the image relative to the element, consistently and b) doesn't wreck the PNG transparency in IE8 by turning partial transparency into pixelated black.
Similar problems occur with any form of transformation - such as scale, rotate etc.
I can't find any good answer to this: the closest I've found is an ugly but functional workaround for IE8 transform (wrapped in if(Raphael.type=='VML')s so you don't spoil things for real browsers):
Before doing any transform to anything that has an alpha transparency PNG / pattern fill, remove the pattern fill (path.attr({fill:'none'});), storing the fill setting like path.data('fill',path.attr('fill'));
After the transform, asynchronously (e.g. wrapped in setTimeout(function(){ })) re-apply the fill e.g. path.attr({fill: path.data('fill')});
The crucial thing seems to be: the fill must not be applied when the transform occurs, else it'll be ruined forever, even if you remove and re-apply it. Be careful with the timing on this - it mustn't be possible for the fill to re-apply before the transform completes (e.g. watch out for race conditions with animations or other async processes).
If you're animating a transform, your options seem to be to either:
Clear the fill before the animation, just accept that there will be no fill while the animation takes place, and re-set in a callback after the animation completes
Implement your own animation handler than removes and re-applies the fill before and after every frame (this, of course, risks being a performance nightmare).
I am trying to rotate a circle image using jquery rotate plugin. But, I observe that the circle image appears to be oscillating about it's center while rotating. Something like a linear movement.
In IE7, it's pretty much observable. In Chrome/Firefox, if you zoom a bit, this wobbling issue can be observed.
I tried to rotate the image using Raphael library too. But still, the circle was wobbling.
Then I rotated the image with a c# program to see if the problem is with the browsers' graphic engine. But even here this issue is observed. I even took various images to see if the circle was imperfect. But, all the images show this behavior.
Can this be happening because of anti aliasing? Or, is it just an optical illusion?
If not, then what else can be the reason?
I am using jqueryrotate plugin rotate method to do this. $('#circleimg').rotate(Position);
Check this jsFiddle. Btw, this is the kind of source code you can include yourself in your question to make answering it easier for others.
http://jsfiddle.net/KyJzQ/
I used this rotate plugin since you did not specify which one you used.
HTML
<img id="circleimg" src="http://i.imgur.com/KgUDClr.png">
<img id="circleimg2" src="http://i.imgur.com/sK4qP6z.png">
JAVASCRIPT
var rot = 0;
window.setInterval(function() {
$('#circleimg').rotate(rot);
$('#circleimg2').rotate(rot);
rot += 1;
},
5
);
I think the circle you've provided is not actually a perfect circle, hence the tiny "oscillations" you see.
I added another circle that I rendered myself. If you zoom in closely enough you will see jagged pixels moving around the edge of my circle, but I don't see any way around this since the jQuery plugin is not actually re-rendering the image. I don't see any of the "oscillating" you mention in my circle.
This issue is more about vector art than it is about programming. Get a nice vector graphics program and render the nicest circle you can. Even the one I made is not really that good. Or use HTML5 and canvas to draw dynamically, rather than moving a static image around.
Has anybody ever had any issues with transitioning the opacity of an SVG text element? I'm using both the fill-opacity style and the stroke-opacity style to fade the text elements into and out of existence. It works fine on most browsers, but doesn't transition at all in Chrome on Mac -- the text just pops in and out all at once.
I tried setting the "opacity" attribute in addition to fill-opacity and stroke-opacity and that does seem to make it work, although now I see a weird flicker effect just before and after the transition runs. It's like it's setting it to opacity=1 for a split second before it sets it to 0 and then transitions to 1.
Another interesting thing is that other shapes (circle, rect) fade in and out just fine with nearly identical code to what I'm using with text.
This does seem to be weirdness with a specific browser, but I'm wondering about other people's experiences with opacity on text elements. Are there tricks to get it to behave consistently?
What version of Chrome are you using? I noticed a bug in Chrome dev some time ago when working on the word cloud but it appears to have been fixed as of 19.0.1077.3 dev. Perhaps the fix hasn't made it into your particular version yet?
In my case, using opacity fixed the problem temporarily. The flicker effect could be due to exponent notation not being parsed for very small numbers; you can try using 1e-6 instead of 0 to get around this.
For an animation I made some months ago I toggled the style and used webkit-transition, in combination with visibility: hidden. This seems to work well. If that doesn't work, you could try transitioning to an opacity near zero.