In bug 44267, Comment #6, Regina explains that LO Draw has an internal precision of 10^{-2} mm; and that's the best the UI offers. However, users often notice objects in Draw/Impress rendered at positions which are not multiples of this value. I had the notion that a fix for bug 103322 would also improve/resolve bug 44267, but: 1. It might not have and 2. A different approach was adopted there. So, we're back to the coordinate precision problem. Coordinate precision must be made consistent - in ODF support and in the LO modules. Options: 1. A common limited precision and everything being rounded to it, e.g. 1.1. 10^{-4} mm 1.2 A per-document setting 2. "unlimited" precision expressed by: 2.1 unlimited-length decimals or 2.2 an unlimited-length numerator/denominator pair, 2.3 etc. 3. Floating-point precision Option 1.1 looks like (?) the easiest to implement. I'm not such a fan of option 3 since it might have strange repercussions but it may be easier to implement than the 2.x options.
There is an option of adopting EMUs (1/36000 mm), which allows for perfect integral representation of both tiny fractions of millimeters and inches. Using integers as much as possible avoids rounding errors. The problem is not only the file format, but also the API, which needs incompatible changes.
(In reply to Mike Kaganski from comment #1) > There is an option of adopting EMUs (1/36000 mm), which allows for perfect > integral representation of both tiny fractions of millimeters and inches. > Using integers as much as possible avoids rounding errors. Sounds reasonable to me, I didn't mean to suggest an exclusive list of options. > The problem is not only the file format, but also the API, which needs > incompatible changes. Ah. I remember facing very staunch pushback about the "existing API" in the face of potential changes (bug 150537). That is a separate and more fundamental discussion than coordinate precision... but I'll just ask: Have developers, or the ESC, considered the possibility of maintaining the old API via some sort of adaptation layer, allowing for more permissiveness in the codebase itself? With the adaptation layer always implemented in terms of the more fluid API? And so that you get the old/stable API by default, but you can opt-in to the more current one with some preprocessor define or extra headers?
(In reply to Eyal Rozenberg from comment #2) > Have developers, or the ESC, considered the possibility of maintaining the > old API via some sort of adaptation layer, allowing for more permissiveness > in the codebase itself? With the adaptation layer always implemented in > terms of the more fluid API? And so that you get the old/stable API by > default, but you can opt-in to the more current one with some preprocessor > define or extra headers? Unless that is unavoidable, I don't think it's reasonable; and we don't see a blocker here yet: it's always easy to introduce a XInterfaceFoo2 over the former XInterfaceFoo, and provide the new methods/properties there, alongside with the old methods. This is how we always solve these problems, and this covers your idea generally.
(In reply to Mike Kaganski from comment #1) > the API, which needs incompatible changes. I see how I used bad / incorrect wording. Sorry. It's not "incompatible". It's just a large set of new interfaces/methods, and also large changes (e.g., in filters code) to use those. But that's all doable, and the scale is expected, given the task.
(In reply to Mike Kaganski from comment #4) > I see how I used bad / incorrect wording. Sorry. It's not "incompatible". > It's just a large set of new interfaces/methods, and also large changes > (e.g., in filters code) to use those. But that's all doable, and the scale > is expected, given the task. So, should we break this down into smaller "bugs" which are more limited in scope, with dependencies, which block this one and will eventually allow its resolution? I phrased this bug from a user's, rather than a developer's, perspective.