I almost make chart, that i need. Now i make this in Rechart.js
I must do this
An i have a few questions
How i can decrease space between bottom text (jun,dec etc...) in Rechart.js
How i can shift the starting point, for example, by 20 pixels, without shrinking the line
How i can customize vertical line when hover ( change color, style, height etc )
If you know at least 1 answer l'll be very thankful
Thank you for any information about this
Related
I would like to create 'n' number of circles along a mouse created vector line when the mouse is clicked and dragged.
This would result in a row of circles which would be a certain distance apart, depending on the number of circles in the line. The first and last circles would be at the point where the mouse was first clicked and then released.
Example: If the line is 1000px long, and 3 circles are required there would be a circle at 0px 500px and 1000px. If the line is 1000px long and 5 circles are required, there would be a point at 0px, 250px, 500px, 750px and 1000px.
I had an attempt at paper.js with the following results, but this is not quite what I need. In this example, the circles follow a free path and are spaced by a set number of pixels.
Click here to see
As an extra, it would be nice to see the path of the mouse line before the mouse is released.
As #NicholasKyriakides wrote in his comment, this can be best implemented using a Path with getPointAt(offset).
I have implemented this in your code example and made it more generic, so you can use any path, not only a straight line.
I have also replaced your circle items with instances of SymbolItem, which is more efficient, because they share a lot of data.
Here is the Sketch
http://d.pr/i/U5bb/4n26fLZr
Here's an example of a chart of ours. Pretty unreadable, yea? Is there an easy, dynamic way avoid this? I've tried implementing a dynamic height, but the problem is I can never seem to find the sweet spot that accommodates a smaller number of bars, and a larger number of bars. I feel like this has to be a problem that others have encountered before. Any help would be appreciated!
I accomplish this by doing the following:
1) determine height of non-data elements on the chart (ie, explicitly set the top and bottom margins, and add them together to get a base_height for the chart
2) determine how much space I want each bar to take, including bar width, and padding between bars, and set as my height_multiplier (I usually end up going for 20-25 pixels, personally)
3) on pulling my data, determine how many bars will be needed, and set as my bar_count
4) calculate: chart_height = base_height + (bar_count * height_multiplier)
5) Pass that value to the html to set the height of the chart's containing element.
If your data will vary so much that the chart height in your example works some times, but then you have as many data points as you've posted there, there simply will not be a 'sweet spot' that will handle both extremes well.
Following is the url to my website
http://projectilepixels.com/beta/
I need the space shuttle to appear "naturally positioned" i.e slightly below the grass at all resolutions above 786 x 1024. However as the grass image as it's width set to 100%, the height is dynamic. Thus the bottom value for the shuttle would also be dynamic. I had initially tried using a simple css % value but that didn't help.
My current attempt uses JavaScript. Following is the code
<script>
$(document).ready(function() {
var grass = $( '#grass' );
var grassHeight = grass.outerHeight() - grass.outerHeight()/100 * 74;
$( '#shuttle_1' ).css("bottom",grassHeight);
});
</script>
The initial script just used
var grassHeight = grass.outerHeight();
however it ended up really messed up.
So, as a temp fix I added the mathematics's that calculates 74% (a solution I didn't really want to use as it uses magic numbers), it seemed to work "fine" on Mozilla at 786 x 1024, however I tested it on chrome at a slightly higher resolution (Can't remember it right now, will check the specific resolution and edit this part soon). I'm new to JavaScript and am under as to what would be the best practice to solve this problem across all browsers and resolutions
Would really appreciate if someone guided me around this problem. I'm open to using css,Javascript as well as jquery.
i would have deffently use $.position in here,
$("#Grass").position({
of: $(shuttle),
my: "top center",
at: "bottom center"
});
that will locate the the grass top line of the grass (its center), below the center of the bottom line on the shuttle
Why dont you develop a few constant values that can be applied to the actual rendered values of the grass image to adjust the placement. Something like:
Lets say the grass image is 500px x 237px but the height of the grass is only 158px – If we want the shuttle to sit right at the crown of the grass, it needs to be offset from the bottom of the screen by 158px – 158 divided by 237 works out (almost magically) to .66667
Since this is a fixed ratio, we can use .66667 to calculate the offset from the bottom of the screen for any size grass image, as long as we know the dimensions of the grass image by multiplying the height and .6667
$(function(){
var OFFSET = .66667; //this value is our shuttle adjustment constant
$( '#shuttle_1' ).css("bottom",($('#grass').height() * OFFSET)); //sets the bottom offset of the shuttle
$( '#shuttle_1' ).css("left",(($('#grass').width()/2)-($( '#shuttle_1' ).width()/2))); //centers the shuttle
});
Here is a JSfiddle demonstrating it.
Online editor with "live preview": there is a textarea on the left and a preview div on the right. Whenever the textarea changes, the preview is updated.
This works well for small documents; for very long documents however, it becomes sluggish, because the preview has lots of DOM elements that are constantly repainted.
It would be better to only send to the preview, the part of the textarea that is currently visible (since it's the one that needs to be previewed).
There is a heuristic way to get the first visible line of the textarea:
determine current scroll offset of the textarea:
offset = scrollTop / scrollHeight
(0 < offset < 1)
the first line that is visible in the textarea is:
(total number of lines) x offset
However this only works for "short" lines, ie lines that don't wrap. In general, the number of "lines" in a textarea is not the number of linebreaks; a long line, without linebreaks, wraps and might occupy many "line spaces".
One could try to calculate the average number of "line spaces" a line occupies (average number of characters between line breaks, width of textarea, size of font...) but this is wildly imprecise.
Is there a way to know the position of the first and last visible characters in a textarea?
Well, as a crazy way for doing it you can look how ACE converts the text into canvas-drawn lines. I assume with this approach you can determine the exact position (or better to say, the exact line objects that are currently visible.
But this could also be a kind of vicious circle if the canvas-generated text is compatible in complexity to what you are having in the preview.
Alternatively you can use a fixed-width font which will give you a knowledge of the exact number of chars in the single line, and thus a way of calculating the exact first / last lines.
In the course of toying with SVG for the first time (using the Raphael library), I've run into a problem positioning dynamic elements on the canvas in such a way that they're completely contained within the canvas. What I'm trying to do is randomly position n words/short phrases.
Since the text is variable, its position needs to be variable as well so what I'm doing is:
Initially creating the text at point 0,0 with no opacity.
Checking the width of the drawn text element using text.getBBox().width.
Setting a new x coordinate as Math.random() * (canvas_width - ( text_width/2 ) - pad).
Altering the x coordinate of the text to the newly set value (text.attr( 'x', x ) ).
Setting the opacity attribute of the text to 1.
I'll be the first to admit that my math acumen is limited, but this seems pretty straightforward. Somehow, I still end up with text running off beyond the right edge of my canvas. For simplicity above, I removed the bit that also sets a minimum x value by adding it to the Math.random() result. It is there, though, and I see the same problem on the leading edge of the canvas.
My understanding (such as it is), is that the Math.random() bits would generate a number between 0 and 1 which could then be multiplied by some number (in my case, the canvas width - half of the text width - some arbitrary padding) to get the outer bound. I'm dividing the width of the text in half because its position on the grid is set at its center.
I hope I've just been staring at this for too long, but is my math that rusty or am I misunderstanding something about the behavior of Math.random(), SVG, text or anything else that's under the hood of this solution?
The answer turned out to be how I was thinking about the Math.random() equation. It's not quite as simple as multiplying by the max and then adding the minimum value (of course). It's really more like establishing a double wide gutter on the right end of the container and then shifting the entire boundary to eat up half of that gutter:
var x = Math.random() * ( canvas_w - 20 - ( text.getBBox().width ) ) + ( text.getBBox().width/2 + 10 );
In English...
You have to double the width of each element you want to account for so you can shift the entire range back by that width to keep things nice and equal. In my case, I want to account for half of the width of the text plus a padding of 10.
For example...
Given a canvas width of 500, a text width of 50 and a desired "gutter" of 10, I create a random number between 0 and 430 (500 - 20 - 50). By adding back the widths I need to account for--half of the text width (25) + the padding (10)--I'm left with a random number between 35 and 465. If my text sits at the outer edges of that boundary, it can only reach as far as the 10 or 490.
Hopefully that's clear enough to make sense. Although it makes sense when I think about it, this kind of thing isn't immediately intuitive to me, so I'm sure I'll be referring back here often.