[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 --- Comment #5 from Eyal Rozenberg --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 --- Comment #4 from Mike Kaganski --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 --- Comment #3 from Mike Kaganski --- (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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 --- Comment #2 from Eyal Rozenberg --- (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? -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 Eyal Rozenberg changed: What|Removed |Added Blocks||112703 Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=112703 [Bug 112703] [META] ODF (XML) bug tracker -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 --- Comment #1 from Mike Kaganski --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 Luke changed: What|Removed |Added See Also||https://bugs.documentfounda ||tion.org/show_bug.cgi?id=10 ||3322 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 Stéphane Guillou (stragu) changed: What|Removed |Added Version|3.5.0 release |Inherited From OOo Blocks||103407 CC||stephane.guillou@libreoffic ||e.org Keywords||needsDevAdvice Referenced Bugs: https://bugs.documentfoundation.org/show_bug.cgi?id=103407 [Bug 103407] [META] Unify behaviour and functions across apps -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 152079] Increase coordinate precision and make it uniform
https://bugs.documentfoundation.org/show_bug.cgi?id=152079 Eyal Rozenberg changed: What|Removed |Added Summary|Increase coordinate |Increase coordinate |precision higher and make |precision and make it |it uniform |uniform -- You are receiving this mail because: You are the assignee for the bug.
