Apache OpenOffice (AOO) Bugzilla – Issue 94698
Ignore manual breaks when the "fit to x pages wide and x pages tall" option is used
Last modified: 2010-05-21 17:24:41 UTC
When printing a sheet that has both manual breaks and the "fit to x pages wide and x pages tall" option, it generates an unexpected result. Calc usually scales down the printable area so small that it's impossible to make out the content. Instead, Calc should disregard manual breaks when the "fit to x pages wide and x pages tall" option is used.
Created attachment 57031 [details] proposed patch
Kohei, why should we disregard manual breaks if "fit to x by y"? User may genuinely want to start new page at certain point, yet fit the printout to x*y pages. Regards, Kirill.
* excel interoperability * we already ignore page breaks for "fit to n pages" * if we don't disregard it, the print layout becomes out of wack. * the logistics of determining page layout correctly when both are taken into account is not as easy as it may seem.
Thanks for your answer. Indeed, Excel ignores manual breaks too. Do we have an issue, which describes our new behavior for "fit to n pages"?
>Do we have an issue, which describes our new behavior for "fit to n pages"? Hmm.... The patch changes the behavior for the "fit to x by y" option, not for the "fit to n pages" option. Did you mean to say "fit to x by y"?
Kohei, I am talking about change that is already silently implemented ("fit to x" case) - we need some kind of reference to point users in forums when this question arises.
Kirill, I haven't seen any issue submitted for the existing behavior (of ignoring breaks for fit to n pages). I checked the CVS history of that implementation code, and it appears to be implemented in the very early days. So, it could be in Hamburg's internal bug tracker.
Yep, you are right - we had this behavior for very long time. Thanks for setting me straight on this.
See issue 54993. A slightly better solution is to ignore manual breaks only in the directions (column or row) where a maximum size is given. *** This issue has been marked as a duplicate of 54993 ***
closing duplicate