When I position objects in a Draw drawing, I often need to have fine control over their position - much finer than 0.01cm (=0.1mm), which is the best resolution at which I can change sizes and positions - at least with the default page size. For example, this is necessary when you want to place a shape just so that the connector from it to another shape will be straight rather than turn. Now, you could argue that no resolution is really sufficient and that I would only be satisfied by have rational numbers, or unlimited arbitrary precision, as the resolution - and maybe you would be right, but this would be arguing about the solution, not the problem. So, what are the options IMO: 1. Fixed resolution, but much better than 0.1mm; say, 1000 times better should be sufficient to approximate infinite resolution for use in preparing documentation for print. 10 times better is not quite enough, 100 times - not sure. 2. Fractional resolution - you can specify a numerator and denominator. This could be an optional feature, i.e. only if you set something in the UI does the denominator box show up, and by default it'll have "0.01 cm" and the numerator will be integral. 3. Floating-point resolution - not sure how well that would work with LO's internals, but it's an option I guess. 4. Unlimited precision digits - always respect the user's manual setting in the position and size box, and use some kind of variable-length bigint-like type to represent these values.
Internally the canvas already positions to 10^-5m increments--or 1/100mm--but by design we limit the GUI widgets to just 2 decimal places. So at best we can position in 10^-4m increments, or the rounded conversion from other measure units (TWIPS, pts, px, ch). For now the project calculates positions as 32-bit integers. Achieving higher precision requires we move to floating point calculations which is being looked at but is a long way from implementation. For now--increasing the UI to 3 decimal places of duplicate bug 44267 is about as far as we can go to expose the limited precision possible with current framework. =-refs-= bug 95812 bug 103322 *** This bug has been marked as a duplicate of bug 44267 ***
(In reply to V Stuart Foote from comment #1) > Achieving higher precision requires we move to floating point calculations > which is being looked at but is a long way from implementation. Or moving to 64-bit integers, which, while costing more space, should present much fewer transition issues relative to going floating-point.