Inaccurate text selection
Max2433BO opened this issue · 13 comments
Hi @DarwinNE
I found a problem with FidoCadJ 0.24.8.
From this code
[FIDOCAD]
FJC C 3.0
FJC B 0.5
TY 111 25 4 3 0 0 0 * b_A2^
TY 133 25 4 3 0 0 0 * b_A1^
TY 154 25 4 3 0 0 0 * b_A0^
TY 112 37 4 3 0 0 0 * b_B2^
TY 134 37 4 3 0 0 0 * b_B1^
TY 155 37 4 3 0 0 0 * b_B0^
TY 150 49 4 3 0 0 0 * b_B0^
TY 159 49 4 3 0 0 0 * b_A0^
TY 129 49 4 3 0 0 0 * b_B0^
TY 138 49 4 3 0 0 0 * b_A1^
TY 108 49 4 3 0 0 0 * b_B0^
TY 117 49 4 3 0 0 0 * b_A2^
TY 129 60 4 3 0 0 0 * b_B1^
TY 138 60 4 3 0 0 0 * b_A0^
TY 108 60 4 3 0 0 0 * b_B1^
TY 117 60 4 3 0 0 0 * b_A1^
TY 87 60 4 3 0 0 0 * b_B1^
TY 96 60 4 3 0 0 0 * b_A2^
TY 108 72 4 3 0 0 0 * b_B2^
TY 117 72 4 3 0 0 0 * b_A0^
TY 87 72 4 3 0 0 0 * b_B2^
TY 96 72 4 3 0 0 0 * b_A1^
TY 66 72 4 3 0 0 0 * b_B2^
TY 75 72 4 3 0 0 0 * b_A2^
LI 64 47 175 47 0
TY 171 26 4 3 0 0 0 * ×
TY 171 38 4 3 0 0 0 * =
TY 171 49 4 3 0 0 0 * +
TY 171 60 4 3 0 0 0 * +
TY 171 72 4 3 0 0 0 * =
LI 64 82 175 82 0
TY 71 86 4 3 0 3 0 * b_P4^
TY 92 86 4 3 0 3 0 * b_P3^
TY 114 86 4 3 0 3 0 * b_P2^
TY 135 86 4 3 0 3 0 * b_P1^
TY 156 86 4 3 0 3 0 * b_P0^
TY 10 87 3 2 0 3 2 * Prodotto finale
TY 30 59 3 2 0 3 11 * Matrice prodotti
TY 38 63 3 2 0 3 11 * parziali
TY 50 86 4 3 0 3 13 * b_P5^
you get this picture:
Now, if you try to select the text , pointing to the red dot (image below), in reality you select the text
.
To select the text , you must point the cursor on the green point.
I hope I have been sufficiently clear ;)
Bye, Max
This can have to do with "snap to grid" switched on. In this setting FidoCadJ can only make a selection from grid point to grid point. This also includes that objects close to each other are chosen because one of their grid points are within the selection.
Solution is to switch of "snap to grid". Now you can make selections close to other objects. Remind that on the background there is always a grid point system with a grid of 1mm.
I'm working on the problem, and it seems to mainly involve short texts, with a single character, although in some cases, even with two characters (besides the index or exponent, I mean).
This is an example for the tests:
[FIDOCAD]
FJC C 3.0
FJC B 0.5
TY 150 49 4 3 0 0 0 * b_B0^
TY 159 49 4 3 0 0 0 * b_A0^
TY 129 49 4 3 0 0 0 * b_B0^
TY 140 49 4 3 0 0 0 * b_A1^
TY 108 49 4 3 0 0 0 * b_B0^
TY 119 49 4 3 0 0 0 * b_A2^
TY 95 66 4 3 0 0 0 * String
TY 159 64 4 3 270 0 0 * String
TY 151 70 4 3 180 0 0 * String
TY 95 62 4 3 0 0 0 * String_String^
TY 92 109 4 3 0 0 0 * String^String_
TY 188 29 4 3 270 0 0 * String^String_
TY 182 29 4 3 270 0 0 * String_String^
TY 120 111 4 3 0 0 0 * String^String_
TY 145 113 4 3 0 0 0 * String^String_
TY 104 28 4 3 0 0 0 * b_B00000^
TY 122 28 4 3 0 0 0 * b_B00000^
TY 139 28 4 3 0 0 0 * b_B00000^
TY 103 38 4 3 0 0 0 * b_B00^
TY 114 38 4 3 0 0 0 * b_B00^
TY 124 38 4 3 0 0 0 * b_B00^
TY 133 38 4 3 0 0 0 * b_B00^
TY 151 74 4 3 180 0 0 * String
TY 163 64 4 3 270 0 0 * String
TY 98 77 4 3 0 0 0 * S_s^
TY 108 77 4 3 0 0 0 * S_s^
TY 103 77 4 3 0 0 0 * S_s^
TY 94 77 4 3 0 0 0 * S_s^
TY 122 79 4 3 0 0 0 * SS_s^
TY 129 79 4 3 0 0 0 * SS_s^
TY 136 79 4 3 0 0 0 * SS_s^
TY 94 92 4 3 0 0 0 * SSS_s^
TY 105 92 4 3 0 0 0 * SSS_s^
TY 116 92 4 3 0 0 0 * SSS_s^
TY 127 92 4 3 0 0 0 * SSS_s^
TY 172 80 4 3 0 0 0 Arial S_s^
TY 177 80 4 3 0 0 0 Arial S_s^
TY 182 80 4 3 0 0 0 Arial S_s^
TY 187 80 4 3 0 0 0 Arial S_s^
TY 173 94 4 3 0 0 0 Arial++Black S_s^
TY 178 94 4 3 0 0 0 Arial++Black S_s^
TY 183 94 4 3 0 0 0 Arial++Black S_s^
TY 188 94 4 3 0 0 0 Arial++Black S_s^
RV 167 77 199 110 0
TY 201 79 4 3 0 0 0 * ARIAL
TY 201 94 4 3 0 0 0 * ARIAL BLACK
With certain fonts like Arial and Arial Black, the problem doesn't seem to occur.
I’m continuing to study the problem. I’ve tried modifying the "getDistanceToPoint()" function in various ways, but with little success.
I’ll pick it up again tomorrow with a fresh mind.
Okay, I think I've figured it out. The problem lies in the handling of tokens for subscripts and superscripts, which cause the string to lengthen as if spaces were added. As a result, the bounding box is not correct.
[FIDOCAD]
FJC B 0.5
TY 73 41 4 3 0 0 0 * \^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TY 73 54 4 3 0 0 0 * \_____________________________
RV 168 38 89 63 0
TY 85 30 4 3 0 0 0 * click to select in this zone
For texts that are very close together, the result is that the bounding boxes overlap, creating a selection problem.
I forced the drawing of the bounding boxes on the texts. As you can see, the problem becomes clear:
@DarwinNE, this was a feature you integrated in the latest release "0.24.8," because I tried it on "0.24.7," and it wasn't implemented. Correct?
I was wondering why you didn't use the "TextAttribute," but thinking about it, I believe the reason is related to minimizing the use of AWT as much as possible...
Superscripts and index are a feature added in 0.24.8.
Yes, it's correct I wanted to avoid AWT.
The problem lies in the getDistanceToPoint() method. Essentially, the getStringWidth() function, which is used to calculate the text length, doesn't account for the fact that control characters like "_", "^", and the backslash present in the string aren't actually drawn. As a result, the bounding box ends up being longer than the text.
The idea would be:
-
Implement
getCharWidth(): Implement this method in the various interfaces and classes to retrieve the actual width of a single character. -
Write a Parser Function: Create a function that parses the string to determine how many control characters it contains. For each control character found, add its width to a variable (
widthOfTotalCtrlChar). -
Adjust Bounding Box: Finally, create the bounding box, taking into account the adjusted string width as follows:
getStringWidth - widthOfTotalCtrlChar.
I would also like to implement some upstream limitations that check the following:
Trimming Input Strings:
Before processing the text, apply the trim() method to remove any leading or trailing spaces.
This can be done wherever the text is initially input or processed.
Check for Consecutive Control Characters:
Implement a function that parses the string and checks for consecutive occurrences of control characters.
If such a pattern is detected, either raise an error or automatically reduce the sequence to a single control character.
Trimming Input Strings:
Why do you think it should be needed?
Check for Consecutive Control Characters:
I don't personally see any occasion where putting two consecutive control characters can be useful, but a string like this is perfectly valid:
TY 62 32 4 3 0 0 0 * Test^^^3_2_1
Why do you think it should be needed?
I don't think there's any point in having empty spaces at the beginning and end of a text; it can only cause alignment issues, at least that's how I see it.
I don't personally see any occasion where putting two consecutive control characters can be useful, but a string like this is perfectly valid:
TY 62 32 4 3 0 0 0 * Test^^^3_2_1
You're right, so the check would only be done if there are control characters (one or more) with nothing else after them. What do you think?
For now, I've had to park it in a local branch. I'm currently focusing on theme integration. I'll get back to it in a few days once I've cooled off a bit. ;-I
I don't think there's any point in having empty spaces at the beginning and end of a text; it can only cause alignment issues, at least that's how I see it.
[...]
You're right, so the check would only be done if there are control characters (one or more) with nothing else after them. What do you think?
If the string does not contain any error, why shall we change it?
But wouldn't something like this be classified as an error?
TY 50 35 4 3 0 0 0 * String_______________
No, it is not an error by itself.
One may object that there is no point in doing this (unless there are some side effects that should be considered bugs and corrected ASAP), but the string does not violate any parsing rule.
The only side effect at the moment is that it increases the bounding box of the text; each control character or space causes it to grow.