is there a particular reason for paranthesis or square brackets for [unit] ?
In some strings the measurment notation is in normal paranthesis (example: Vertical shift (px)), while in other strings the notation is in square bracket (example: Radius [px]).
Is there any particular reason for one or another ?
Cristi
2010/6/3 Cristian Secară <orice@...245...>:
In some strings the measurment notation is in normal paranthesis (example: Vertical shift (px)), while in other strings the notation is in square bracket (example: Radius [px]).
Is there any particular reason for one or another ?
I wouldn't think there is really. I suspect it simply depends on who wrote the initial string.
Perhaps someone who knows English punctuation and editorial rules could say which is correct.
Regards, Marcin
Ühel kenal päeval, N, 2010-06-03 kell 21:53, kirjutas Marcin Floryan:
2010/6/3 Cristian Secară <orice@...245...>:
In some strings the measurment notation is in normal paranthesis (example: Vertical shift (px)), while in other strings the notation is in square bracket (example: Radius [px]).
Is there any particular reason for one or another ?
I wouldn't think there is really. I suspect it simply depends on who wrote the initial string.
Perhaps someone who knows English punctuation and editorial rules could say which is correct.
Regards, Marcin
Square brackets [] are sometimes preferred enclosure for dimensions, at least in physics, I myself like this style.
You even could define dimension for a variable apart from value like [v]=m/s or have a heading for table like "Length l [m]".
Mattias
This is part of the bug 560751 (https://bugs.launchpad.net/bugs/560751). I would really like to see something more general, whatever the outcome would be.
2010/6/4 Mattias Põldaru <mahfiaz@...5...>:
Square brackets [] are sometimes preferred enclosure for dimensions, at least in physics, I myself like this style.
You even could define dimension for a variable apart from value like [v]=m/s or have a heading for table like "Length l [m]".
As far as I know, this is not true. The square brackets indicate that what what you want to show next is the dimension of what is between the brackets. In other words, you would write the sentence: "The dimension of speed is meters per second" as: [v] = m/s
But this is not the same as a value of a physical quantity with its unit. Either though the dimension of speed is m/s, you can also write values in mm/s. This is what you indicate in your second example which is an incorrect reasoningn ("Length l [m]").
Anyhow, I would kindly appreciate it if there are some more comments on how to show units in the standard Inkscape interface (remember that if translating you can choose your own style as reporting units may be language dependant).
Kris
Ühel kenal päeval, R, 2010-06-04 kell 08:23, kirjutas Kris De Gussem:
This is part of the bug 560751 (https://bugs.launchpad.net/bugs/560751). I would really like to see something more general, whatever the outcome would be.
2010/6/4 Mattias Põldaru <mahfiaz@...5...>:
Square brackets [] are sometimes preferred enclosure for dimensions, at least in physics, I myself like this style.
You even could define dimension for a variable apart from value like [v]=m/s or have a heading for table like "Length l [m]".
As far as I know, this is not true. The square brackets indicate that what what you want to show next is the dimension of what is between the brackets. In other words, you would write the sentence: "The dimension of speed is meters per second" as: [v] = m/s
But this is not the same as a value of a physical quantity with its unit. Either though the dimension of speed is m/s, you can also write values in mm/s. This is what you indicate in your second example which is an incorrect reasoningn ("Length l [m]").
Thanks you for your kind explanation :)
Mattias
Anyhow, I would kindly appreciate it if there are some more comments on how to show units in the standard Inkscape interface (remember that if translating you can choose your own style as reporting units may be language dependant).
Kris
participants (4)
-
Cristian Secară -
Kris De Gussem -
Marcin Floryan -
Mattias Põldaru