https://bugs.documentfoundation.org/show_bug.cgi?id=162079
--- Comment #3 from Mike Kaganski <[email protected]> --- (In reply to Eyal Rozenberg from comment #2) > Mike, what is the situation today w.r.t. the internal representation of > coordinates? This is not simple. On the public API side, it is sal_Int32; and we need to add interfaces with 64-bit types. But first, we need to use a 64-bit type internally. And that is not done decidedly: we use tools::Long as an intermediate type, which is created as 64-bit type on 64-bit platforms (including 64-bit Windows), and 32-bit on 32-bit platforms. So it is not uniform. Until we support 32-bit platforms in any way; or until we bite the bullet, and decide that we use 64-bit coordinates on 32-bit platforms, too - we can't move forward. Another issue is the unit that we should use for our coordinates (which is very important when speaking about extending the API). We use integers with 1/100ths of a mm in the API; and we use either twips (Writer, Calc), or 1/100ths of mm (Impress/Draw) in the model. In case of Writer/Calc, that adds more conversion errors; but most importantly, that's not a good enough precision. We should really think of using either doubles, or EMUs (strictly 1/36000 mm, strictly 1/914400 in). Using these with a signed 64-bit integral type, 2^63 EMUs is 2.5^8 km. Of course, this would introduce a transitional period of having an API using EMUs, and internally still using old units... -- You are receiving this mail because: You are the assignee for the bug.
