Created attachment 23545 [details] Fix cursor in text elements While playing with cursors a bit, I noticed a weird behavior with pointer cursors... Further analysis and comparison with release 1.7 lead to the conclusion that this was a regression introduced with revision 761228. Steps to reproduce: 1. Load the bug report URL [1] in Batik Squiggle; 2. Place the mouse pointer over "Text Cursor" and move around. Expected results: A text cursor would be shown always. Actual results: A pointer cursor is sometimes displayed. Additional information: After digging down a bit, it seems that a necessary coordinate transform was removed during revision 761228. The patch addresses this by restoring it. I've also checked that the example [2] posted into the mailing list -- which somehow triggered the changes -- still works flawlessly with the patch applied. [1] http://www.w3.org/Graphics/SVG/Test/20061213/svggen/interact-cursor-01-f.svg [2] http://www.nabble.com/attachment/22824226/0/Batik-EventsAndZoomIssues.svg
I can't reproduce this bug. It's hard for me to see how the bug described bug could be caused by this. The block of code you updated is only used to locate tspan's within a text element. There are no tspans in this example. Your proposed patch will cause problems. rev 761228 changed the way that block of code works so that 'pt' must already be in the elements local coordinate system. So applying that transform again will cause trouble. There actually was/is a bug with version="1.2" documents, which I will commit shortly, but this document couldn't trigger it (since it's version="1.1"), and it didn't have any tspan elements.
(In reply to comment #1) > I can't reproduce this bug. Weird, I still can. Just tried with an untouched fresh Batik checkout (revision 768952). made a "build clean", "build squiggle" and opened the report's URL. Nevertheless, I forgot to mention a couple of things in the original report: * This was originally seen in a machine with Windows Vista SP1; * Java environment is Sun's JDK 1.6.0 update 13; * This reproduces with a Squiggle windows which is not maximized. > It's hard for me to see how the bug described bug could be > caused by this. The block of code you updated is only used > to locate tspan's within a text element. There are no tspans > in this example. Maybe the anchor within the text element will make Batik internally handle that text portion as in a tspan (but then again, I'm just guessing...)? I was also able to reproduce using different configurations: * In a (different) machine with Windows XP SP3 and both Sun's JDK 1.6.0 update 13 and JDK 1.5.0 update 17; * In a (yet different) machine using Ubuntu 8.10 and Sun's Java 1.6 with a Batik nightly build [1]; (This suggest towards something which affects all platforms -- I'm setting it, even though Mac wasn't tried.) Few more thoughts: * Using a windows size of 800x600 makes the issue reproducible (that is, the unexpected pointer cursor appearing on top of the "Text Cursor" glyphs); * This can also be checked by placing the mouse pointer over the glyphs of "Pointer Cursor", which should display a pointer cursor (and most times doesn't); * Applying the proposed patch, "build clean", "build squiggle" and opened the report's URL no longer reproduces the error (attempted with maximized and also with several window sizes for sure). > Your proposed patch will cause problems. rev 761228 changed > the way that block of code works so that 'pt' must already be > in the elements local coordinate system. So applying that > transform again will cause trouble. Humm... But I was still suffering from the issue without the patched code (patching it makes the weird cursor behavior to go away, both with Java 1.5 and Java 1.6). As I'm not able to quite understand the changes in "StrokingTextPainter.java", the only things that also occurs to me is that some local changes were not committed...? I'm not sure what kind of additional information can I provide in order to help reducing this... :-| [1] http://arc.mcc.id.au/batik-nightly/webstart/squiggle.pl
I fixed the bug. It took me a while but I finally figured out that you were talking about the title text "Text Cursor" not the text cursor test box. Your patch would actually work since the documentation for getPoint2D() was wrong. I've made the implementation match the documentation (see rev 769733). So your patch isn't needed.
(In reply to comment #3) > I fixed the bug. Great! :-) > It took me a while but I finally figured out that you were > talking about the title text "Text Cursor" not the text cursor test box. Yeah, I admit that it was somehow tricky, as it was a test specifically testing cursors. Guess I should have made the text a bit more clear regarding that... > Your patch would actually work since the documentation for getPoint2D() > was wrong. I've made the implementation match the documentation > (see rev 769733). So your patch isn't needed. Even better. :-)