Bug 152079 - Increase coordinate precision and make it uniform
Summary: Increase coordinate precision and make it uniform
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: 44267 Unify-Across-Apps ODF 162079
  Show dependency treegraph
 
Reported: 2022-11-16 22:56 UTC by Eyal Rozenberg
Modified: 2024-07-18 22:17 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2022-11-16 22:56:19 UTC
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.
Comment 1 Mike Kaganski 2022-11-20 19:23:21 UTC
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.
Comment 2 Eyal Rozenberg 2022-11-20 21:40:14 UTC
(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?
Comment 3 Mike Kaganski 2022-11-21 05:16:39 UTC
(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.
Comment 4 Mike Kaganski 2022-11-21 05:38:56 UTC
(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.
Comment 5 Eyal Rozenberg 2022-11-21 09:11:38 UTC
(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.