Summary: | Increase coordinate precision and make it uniform | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Eyal Rozenberg <eyalroz1> |
Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | aron.budea, caolan.mcnamara, cyaugin, lukebenes, rb.henschel, stephane.guillou, telesto, toobuntu |
Priority: | medium | Keywords: | needsDevAdvice |
Version: | Inherited From OOo | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=108975 https://bugs.documentfoundation.org/show_bug.cgi?id=103322 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 44267, 103407, 112703 |
Description
Eyal Rozenberg
2022-11-16 22:56:19 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. (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. |