At the moment, if you move an object away from the drawing page, after not very far away - Draw prevents you from moving it further. That should not happen. The user should be able to define what size their canvas will be - by moving objects further out. The rectangle containing all objects + the page should be the canvas size at any given time. This expected behavior seems to be what Inkscape does, for example.
See: https://bz.apache.org/ooo/show_bug.cgi?id=4219#c32
(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).
(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...
(In reply to Mike Kaganski from comment #3) > 2.5^8 km Sorry for the typo; of course, it's 2.5*10^8.
(In reply to Mike Kaganski from comment #3) While this is of course not at all my call, I would say: Get things right internally, then change or add to the APIs. > 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. So there are both the issues of precision, and the choice of units... Anyway, this is a throwback to bug 152079. I suppose we can make this bug depend on that one. > Of course, this would introduce a transitional > period of having an API using EMUs, and internally still using old units... Don't you mean the other way around?
(In reply to Eyal Rozenberg from comment #5) > > Of course, this would introduce a transitional > > period of having an API using EMUs, and internally still using old units... > > Don't you mean the other way around? No I don't. I might be mistaken, but I believe, that we would have to implement the API first, to allow the transition - because some *internal* code uses the API, and so without the API, it would be impossible to do some changes. It could be interleaved, of course - some doable internal refactor without the API, then the required API additions, then the rest. Let me state on the literal "Drop the limit on canvas size" wording. I believe that we should make it *practically* fitting any office task. But we shouldn't make it really unlimited in the strict sense, like using bigints. So, e.g. making is 100m x 100m canvas would IMO be more then enough. It would enable its use for any kind of a banner, with enough space beyond. The specific numbers may be discussed, of course (well, the current 1/3rd page size limit, adding one more page size on each side, would make page limit of 33 m then; and of course, with *that* page size, we are back to the problem discussed here; it is questionable if we must guarantee "unlimited" canvas in such extreme uses). 100m canvas has the upside that it lets multiply two such numbers, and still be in the 64-bit integer range (it is a common intermediate value), because 100m is 3 600 000 000 EMU (in 32 bit unsigned range, so needs intermediate unsigned arithmetics). 50m limit would enable even signed intermediate values in 64-bit range. OTOH, there is Calc, with its 2^20 rows (let alone its jumbo mode with 2^24 rows), which, when all set e.g. to 10 cm high, would require 105 km. Since users are expected to do things like "select all, format" kind of thing, we should consider that. In practice, Calc is the most demanding app here.