Double bug report (don’t be aware of the length of this post :P )
I found this while testing, but researching about it I found the root cause, that is specific. This second bug can be something difficult to achieve, depending how LL is saving this data.
Ok, let’s stop writing abstractly. These are the bugs:
[1] The geometry editor don’t want you to use decimals…if you are Spaniard (some other languages as well)
To be honest I can’t say if this bug was here before…maybe it was since the geometry editor was added!
The bug is simple: the float numbers that you can input in the geometry editor takes ‘.’ dots as the separator between decimals. If your mobile phone is set to a language that use this notation, all is ok.
But if, like Spanish and other languages, you use the ‘,’ comma instead, the geometry editor show the number with the comma, as well as the prompt window…so you need to change it to a dot every time you want to input a new number! Remember that it takes the number with dot, no comma.
Solution? Don’t let the system choose the decimal character, or make the editor to also accept commas.
Note: maybe this happen with other float inputs in other settings as well.
[2] half a pixel? Please no
As the title say, it’s physically impossible to have 1/2 pixel (1/3 , 6/19 , …)
So…why you can set the position of items with decimals?
This is not a silly question, and the answer you can think of is: ‘because you can zoom’
…
Nice try, but no. If an item is at 1.75 it is rounded and placed at 2 even with the biggest zoom. It’s easy to try, just add two identical shortcuts, one placed at ( 0 , 1 ) the other at ( 0.4 , 0.5 ) for example. They will look identical. (Maybe you think this is not very important, it’s only 0.1 more. But remember I’m talking when zoom, and a one pixel line can have the size of the screen, believe me it matters)
So…why? Why don’t just only let the user set it as integers, like with size?
If there is a ‘hidden’ reason, maybe you can alert it when using the .getPositionX/Y … I was crazy trying to figure why my script (will be posted soon) didn’t work with zoom. Then I realized it get fixed just using Math.round( .getPositionX/Y )
(And I have been trying to figure this out since 10.0 version was release. But hey, because of this I found the setPosition(,,,false) bug and this one. Not bad)
Oh, and I also think I know how the .translateIntoScreenCoordX/Y work…because it has also the bug ;)
]]>
< ![CDATA[
I am ok with 1) !
“half a pixel” is totally valid. Actually coordinates are all floating points, from the rendering layer to LL because most things are not dependent from the rendering device (here: a screen with pixels). When the geometry need to be converted into pixels, having precise coordinates is important for scaling ot to compute anti aliasing for instance. Usually a vertical line with x=0 will be drawn a bit on pixel -1 and pixel 0. A line with x=0.5 will exactly match one pixel.
]]>
< ![CDATA[
Pierre Hébert hi again!
Ok I understand. But all the tests I made shown that items are placed at rounded pixels, so if you make scripts with those values, the position is ‘wrong’.
Now I know, but maybe you can alert it…not sure
]]>
< ![CDATA[
Precisely because it avoids blurring due to aliasing 🙁 Agreed this is only valid at scale 1. Under 1 everything will be blurred, and above 1 it does not really matter neither.
]]>