Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | JavaScript Vector Library edit |
-
Vertical positioning of elements created with raphael.print is not correct, as illustrated by
http://dl.getdropbox.com/u/223827/raphael/raphaelprinttest.html
where each colored element should be somewhere on the correspondingly colored line.The culprit seems to be the line:
out.scale(scale, scale, 0, y).translate(x, (size || 16) / 2);The "obvious" fix:
out.scale(scale, scale, 0, 0).translate(x, y);seems to produce a behaviour that is at least consistent, if not correct:
http://dl.getdropbox.com/u/223827/raphael/raphaelpatchedprinttest.htmlThere must however be some reason why the more "obvious" line is not what was written. What is the correct desired behaviour?
Comments
-
Only text and path
var canvas = Raphael(0, 0, 500, 500);
var p = canvas.path();
var t = canvas.text(100, 200, "aaaaaaaaaaaaa\nbbbbbbbbb");
redraw = function() {
p.attr("path", "M0,0 L100,200");
t.attr("x", 100).attr("y", 200);
}resize = function() {
canvas.setSize(800, 800);
}setTimeout(redraw, 100);
setTimeout(resize, 2000);
setTimeout(redraw, 2500);Comments
-
0 votes
c.attr("hide") / c.attr("show") should return boolean
2 comments Created 3 days ago by chasbeenvar c = paper.circle(10, 10, 10);
c.hide();
alert(c.attr("hide"));//returns "undefined"Comments
-
This line (1137 [v1.2.3]) creates an error when
xy[i]is equal to-1.xy = [-1, -1]; translate.call(o, (+xy[0] + 1 || 2) - 1, (+xy[1] + 1 || 2) - 1);
Step through:
translate.call(o, (-1 + 1 || 2) - 1, (-1 + 1 || 2) - 1); translate.call(o, (0 || 2) - 1, (0 || 2) - 1); translate.call(o, (2) - 1, (2) - 1); translate.call(o, 1, 1);
Comments
-
0 votes
A rounded rectangle in IE7 requires re-registering of shape mouse events after dimension changes
var c = paper.rect(200, 200, 200, 100, 15).attr("fill", "blue");
c.mousedown(getMouseDown()); //will not fire
c.mouseup(getMouseUp()); //will not fire
c.attr({"width":100, "height":50}); //due to thisthe same works if it is a normal rectangle or the rounded corner is set to 0
A rounded rectangle in IE7 requires re-registering of shape mouse events after dimension changes
To make it work the events have to be re-registered
var c = paper.rect(200, 200, 200, 100, 15).attr("fill", "blue");
c.mousedown(getMouseDown()); //will not fire
c.mouseup(getMouseUp()); //will not fire
c.attr({"width":100, "height":50}); //due to this
c.mousedown(getMouseDown()); //will fire now
c.mouseup(getMouseUp()); //will fire nowComments
-
Here is some test code, which I have been trying at http://raphaeljs.com/playground.html
var target = paper.rect(10, 10, 100, 100, 10);
target.attr({y: 20, width: 200, height: 200, "stroke-dasharray": "- "});
target.remove();If you take any of the attribute updates out, or get rid of the radius, the rectangle is removed uccessfully, but in this case an error is thrown. (Only in IE).
There's a possible fix for it in my fork of the code on github:
http://github.com/jamesots/raphael/commit/70af89034027010af0a219dfa3b7fc8b5b2b77c8Comments
-
Using Safari 3.2.1, see:
http://raphaeljs.com/analytics.htmlText is drawn immediately on hover, and stays where its bounding box was located at this time. The bounding box continues to move to follow the mouse properly, leaving the text behind.
Also, text vertical alignment issues on gRaphael bar and pie graphs:
http://g.raphaeljs.com/piechart2.html
http://g.raphaeljs.com/barchart2.html
Comments
-
text vertical alignment is different in browsers, any clean solutions?
I got this weird text alignment issue, if I set text to var test = paper.text(30, 22, "something);
and then
test.remove();
and again
test = paper.text(30, 22, "something);
vertical alignment for y becomes 26 in FF and chrome, any ideas?Thank you
Comments
Another example is http://astrolin.com/zodiac - the Y coordinate for each symbol is the same as for every + mark, yet they grow further off with bigger Y values.
I have updated the above test case with the latest release. I don't understand what the introduced top and height are supposed to do, but I don't think it works.
Having re-read it I now think I understand. However, the precise positionning of text will be extremely difficult with this method. The alignment of glyphs in fonts is designed to be on the 0,0 coordinate and should not be on the top of the font bounding-box. Unless there is some spec which contradicts my claim...
Raphaël aligns glyphs vertically to the middle of bounding box. It works fine for major cases. What alignment do you suggest?
I assume that the inter-glyph alignment is fine (although I wonder whether the baseline property should not be taken into account). However, I think the coordinate positioning should possibly be that of the baseline, otherwise, in order to precisely position a glyph, one must take into account the bbox property to "reverse" the work you have already done. (not that it matters too much at small font sizes, but at large font sizes, as the xy coord is that of the top/left of the font's bbox, the glyph itself may be postioned far from it). I will try to find some time to investigate further. What are the "major cases" you have tested against?
Thanks for taking the time to account for this stuff.
I have updated my test case using origin="baseline". Still broken - glyphs at different sizes are not aligned in a meaningful way. In the absence of font.baseline, the baseline should probably be considered as zero (i.e. top==0 and height == 0). Or do you have a test case where this is plainly incorrect behaviour?
I have stopped using the Raphael.print function as I only use it to print individual paths (which I obtain from a font as this is the easiest source of these paths for me). I now just print the paths and translate them. In absence of bug reports by others, don't worry too much about fixing this.