https://bugs.documentfoundation.org/show_bug.cgi?id=162079
--- Comment #6 from Mike Kaganski <[email protected]> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
