Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
-Matthew
On 2013-06-18 04:06, Matthew Petroff wrote:
Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
Don't forget to take sp-metric(s) into account. Other than that: keep up the good work!
On 18-6-2013 4:06, Matthew Petroff wrote:
Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
-Matthew
For the people that want to follow his progress: https://code.launchpad.net/~matthewpetroff/inkscape/gsoc-2013-unit-refactor
Cheers, Johan
On 18-6-2013 4:06, Matthew Petroff wrote:
Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
Something to add to the list is "lossless" storing of dimensions and units. I.e., if working with mm as document unit, 10mm should stay 10mm without rounding errors sneaking in and turning it into 10.00001mm.
Ciao, Johan
On Thu, Jun 20, 2013 at 11:48:09PM +0200, Johan Engelen wrote:
On 18-6-2013 4:06, Matthew Petroff wrote:
Over the past two weeks, I have looked at Inkscape's code, outlined existing unit support, and planned my approach to refactoring it.
http://www.mpetroff.net/archives/2013/06/17/current-state-of-units/
Something to add to the list is "lossless" storing of dimensions and units. I.e., if working with mm as document unit, 10mm should stay 10mm without rounding errors sneaking in and turning it into 10.00001mm.
This brings up an interesting/important point: what is the correct interpretation of 10mm. Is it more precise or less precise than 10.000mm, 10.001mm? [1]
To the mathematician me, 10 == 10.000, 10 != 10.001 To the engineering me, 10 == 10.000 == 10.001; but 10.000 != 10.001
This is one reason why scientific notation is so elegant - the precision is encoded in the number of digits in the mantisa. 1e1 is less precise than 1.0e1, the first is expected to only be right to the first digit, the second to 2 digits.
We could have a numeric class which keeps track of both the value and the precision and correctly propagates these. Better still would be to use something like affine arithmetic which gives fairly tight bounds on the true precision, all the time maintaining a conservative bound on the error. This would tie in nicely to better boolean ops and the various clipping operations which we have talked about for the last decade or so :) Furthermore, the same machinery for affine arithmetic can also be used to implement some of the logic for 'px' vs '%' vs 'mm' units - we can treat these three as having separate variables (in the statistics sense) and the calculation will work out correctly.
njh [1] We can't do much about accuracy :)
Nathan Hurst wrote
This brings up an interesting/important point: what is the correct interpretation of 10mm. Is it more precise or less precise than 10.000mm, 10.001mm? [1]
To the mathematician me, 10 == 10.000, 10 != 10.001 To the engineering me, 10 == 10.000 == 10.001; but 10.000 != 10.001
I would not add another issue to the existing one. I agree on your considerations and that's why I bear with Inkscape's view of precision but the original problem is different: we are speaking about a computer program in which if you enter 10 mm and it's internally stored as 10 mm, it will always be 10.00000000000000.... mm. Of course the numbers are doubles so 10.23 mm may be internally stored as 10.22999999999999999999... mm but it should always be that exact quantity until some math is going to change it. I expect no "translate" nor "copy-paste" nor "change-width" or similar math to introduce errors, while if you rotate or rescale surely your "exact" quantity is going to change slightly (and here the point that Inkscape is not a CAD becomes quite important). Hence, to deal with precision, you should store the originally entered value together with the history of the operations applied to the object (or at least a reference to which is the measure to compare to the original value), and always check that the final result is inside a specified precision (in which unit?)...
Personally, I would be glad to simply have my mm lengths preserved, for example, after saving and reopening the document. This is a much less complicated and philosophical issue, that doesn't involve anything but avoiding corrupting documents with unwanted-unexpected unit translations. After this basic result has been achieved, we could speak about what a user means when entering "10 mm" and what Inkscape means when replying "10.000 mm".
Matthew, looking forward to see your results: all the best for your work.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-Existing-Unit-Support-tp4967149p49671... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Personally, I would be glad to simply have my mm lengths preserved, for example, after saving and reopening the document. This is a much less complicated and philosophical issue, that doesn't involve anything but avoiding corrupting documents with unwanted-unexpected unit translations.
I agree. Note that by using the viewbox attribute, I think this mostly works already. Initially after creating an object, there are extra transformations, but if you move the object once, the values seem to be directly used.
Cheers, vaifrax
participants (6)
-
Jasper van de Gronde -
Johan Engelen -
LucaDC -
Matthew Petroff -
Nathan Hurst -
vaifrax