0

I'm using D3js and I have plotted a graph that works like this (edit: new fiddle with JSON data)

I'm actually using an external JSON file for my data.

var data=[{name:'fruits', value:2},{name:'veggies', value:3},{name:'milk', value:5},{name:'empty', value:0}];

My problem is that when I open the file in another system with a different resolution, the line that I'm plotting works backwards. I think the problem is due to the different resolution or could it be because of something else. Can someone help me to solve this problem.

Thanks in advance...

user2928041
  • 31
  • 2
  • 8
  • In the jsfiddle example, the data plotted uses 'x' and 'y', both of which are numbers. Your datum comprises a string and integer. I am failing to see the similarity. Can you share your code? – Shashank Agarwal Feb 10 '14 at 20:26
  • Which other system? We've run into a bug with this stroke animation feature on Firefox for Windows. [See here](https://bugzilla.mozilla.org/show_bug.cgi?id=661812). – meetamit Feb 10 '14 at 23:31
  • I meant another laptop which runs on Linux. I use Windows 7 and din't have any problem with my plot transition (my new fiddle). But, the transition of the plot was either moving backwards (Windows 7 Firefox another Laptop)or remains static in Linux. Is there a way to fix it. – user2928041 Feb 11 '14 at 10:33
  • I've run into this, and agree with OP that there are differing implementations in different browsers. Chrome desktop 36.0.1985.125 considers one end of my path to be the "beginning", while Safari on iOS7 considers it to be the other. Am right now considering platform detection (with an Array.reverse() for iOS) as my only apparent solution. – Felix Weelix Aug 31 '14 at 13:44

2 Answers2

4

I'm not sure where you got the code for the version of the stroke dash transition that you're using, but I can see why it would create unusual behaviour in some browsers:

path1.attr("stroke-dasharray", totalLength + " " + totalLength)
 .attr("stroke-dashoffset", totalLength)
 .transition()
 .duration(duration)
 .ease("linear")
 .attr("stroke-dashoffset", 0);

You're defining a dash pattern consisting of a solid dash the entire length of the line, followed by a gap that is also the length of the line, initially offset by the length of the line and transitioning to zero offset. With that information, and with the unfortunately vague definition of the stroke-dashoffset property in the specs ( " ‘stroke-dashoffset’ specifies the distance into the dash pattern to start the dash" ), I really have no idea what should be the outcome.

Try using:

path1.attr("stroke-dasharray", 0 + " " + totalLength)
 .transition()
 .duration(duration)
 .ease("linear")
 .attr("stroke-dasharray",  totalLength + " " + 0);

That tells it to start with a zero-length dash and a gap the entire length of the path, and transition to having a dash the entire length of the path and a zero-length gap. I don't have Linux to test it out, but I suspect it should work anywhere.

AmeliaBR
  • 27,344
  • 6
  • 86
  • 119
  • This code still creates a reverse animation in mac os x...? – ratata Aug 13 '14 at 00:05
  • The second code block? That is a bug, I haven't seen. Can you be more specific? What browser are you using? And by "backwards", do you mean that it goes from fully stroked to zero, or that it starts drawing at the wrong end of the path? – AmeliaBR Aug 13 '14 at 00:20
  • it starts drawing at the wrong end in chrome, firefox. – ratata Aug 13 '14 at 00:22
  • Sorry. I have solved it. The starting point of the path(M) is important. – ratata Aug 13 '14 at 00:44
0

I ran into the same problem and fixed it by adding this line of code:

data.sort(function(a, b){ return d3.descending(a.foo, b.foo); });

or

data.sort(function(a, b){ return d3.ascending(a.foo, b.foo); });

This will sort your data descending or ascending forcing the animation to run a different direction, depending which one works for you.

Joe Komputer
  • 1,325
  • 3
  • 12
  • 25