https://bugs.documentfoundation.org/show_bug.cgi?id=162079
Eyal Rozenberg <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Eyal Rozenberg <[email protected]> --- (In reply to Mike Kaganski from comment #1) That is some very good context. historical context. In fact, let's actually quote that passage (not including the future plans) > AW: Reason is that the DrawingLayer internally is (still) based on 32bit > integer coordinates and uses 1/100th mm. Together with the area surrounding > the page (where You can place objects, too) it's an area of 3x page size. > So 2.2 billion (signed integer) allows a theoretical max of 22 x 22 Km > (21,47483648 exactly), so the page may be up to 7,1 x 7,1 km big, > theoretically. > > BUT: There is a huge amount of integer-based calculations working on that, > so You need some security distance for numerical reasons. Those are not (at > least not all) numerically safe (!). There is no good argument for the > current limit, but one thing is clear: Each expansion of the limit will raise > the possibilities for numerical errors and nonsense happening in DrawingLayer > due to numerical errors (quadratic?). At least the current limit is tested by > users. > Do not forget that You can also define a scaling in Tools/optins somewhere > which will also use some of the available internal precision. You will run in > trouble with huge values here. > > So i would not recommend to change it for OOo2.0. Mike, what is the situation today w.r.t. the internal representation of coordinates? * Are they integral or floating-point? * Are they 32-bit, 64-bit, variable-size? Also, Armin's words indicate there are two kinds of directions for addressing this issue: * Relaxing the arbitrary limit by a lot, so that the user would likely not notice it (e.g. many thousands of times larger than the page area) - perhaps based on the coordinates now being 64-bits and thus being more flexible, or even regardless of that; * Supporting unlimited coordinates via some kind of BigInt/variable-size class - not for everything, but at least for "far" objects (and you could bin objects into far and near ones, where near ones work faster since they have fixed coordinate size). -- You are receiving this mail because: You are the assignee for the bug.
