As is described in the online documentation here:
You should be able to leave one or both of the height/width options blank:
"You may clear one of the boxes, then the unspecified dimension will use as many pages as necessary. If you clear both boxes, this will result in a scaling factor of 100%."
This is not the behavior in LibreOffice 18.104.22.168 or 4.2 alpha0.
When attempting to leave those fields blank it resets to '1'. The same happens when you attempt to set them to '0'.
Has this been changed purposefully? In previous versions, leaving the height/width field blank seemed to be the only method for allowing manual manipulation of the page breaks in Page Break Preview. Now, to my knowledge, there is no way to select the "Fit print range(s) to width/height" scale option, set the width (so vertical page breaks remain constant), and then manually drag the horizontal page breaks up/down in Page Break Preview.
Very unlikely that this was on purpose, confirmed on 4.1alpha so it must have happened when dialogs were being updated prior to release of 4.1 stable.
Minor (can slow down work but won't prevent high quality work)
High (recent regression)
a740a696eb4c2c7e2baa3e784d15b4d1156cf90b is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Wed Oct 16 21:38:00 2013 +0000
Author: Michael Meeks <firstname.lastname@example.org>
AuthorDate: Thu Apr 4 11:07:54 2013 +0100
Commit: Michael Meeks <email@example.com>
CommitDate: Thu Apr 4 11:17:21 2013 +0100
unwind tangled mess around spinner buttons
Restore removed spinner artwork, cleanup the code: hicontrast - is now
a function of icon theme, not a global boolean.
uwith thanks to Ariel Constenla-Haile)
:100644 100644 64d261b4291fe444b80068efa8911fe6b2d62e7d f1265c5592105896d12b1acb60ce6b5b04318cf7 M ccache.log
:100644 100644 0b4a914f04a25007e396a9398d9f1ccd2ff689d1 54518cbaf493226017cacae67abaa92694a1ecc0 M commitmsg
:100644 100644 2258d830f9c06110ec7004b59574916d64024245 4946aa0976b2dd0df91f98c690c4d08a0738b355 M dev-install.log
:100644 100644 bfefb4eceaffb811fd32c0d72218e57a26e19dc7 814670879f955c5889813fad0a77ac18ba8cf972 M make.log
:040000 040000 a49659521c914bc0c75affec1b7e1c4373849fe6 af916437809240a7ac146739a7ff8a6aaa7ab543 M opt
# bad: [25428b1e953636f74986622c5df614f04c150ed1] source-hash-cb4e009c4539c535108021934e545194b35cad9d
# good: [f0f6c65eb764f0303f59c58d320e9b0d5a894377] source-hash-4b9740b4ec3987e1d4d2ad6d20b4dcf996a4fa2e
git bisect start 'latest' 'oldest'
# bad: [a72833796a7e527d9efc9ca6d8fe9b579e469105] source-hash-1472b5f87314fe660ef1a7b254e51272669f12f6
git bisect bad a72833796a7e527d9efc9ca6d8fe9b579e469105
# good: [4300c48268179afe8db66410fad04436183407cd] source-hash-753310b7db6a36aeaae36cef3bfca970e9310569
git bisect good 4300c48268179afe8db66410fad04436183407cd
# bad: [1a525dcbdb43f56df149158521461b80a18ea7ae] source-hash-d74ba0c4147f33abd9d0c03883cc88f15e160ee5
git bisect bad 1a525dcbdb43f56df149158521461b80a18ea7ae
# good: [ef97d7e08a803ce3b245343405d40e2cfa3f2470] source-hash-ce9bf0f868304a95ace987f90dcf2466e70bfe51
git bisect good ef97d7e08a803ce3b245343405d40e2cfa3f2470
# bad: [5e91b7c70d73beae5b0e57676f101b37750b2124] source-hash-ba044b1e9613ed30906a9a540b7da8392923e4e3
git bisect bad 5e91b7c70d73beae5b0e57676f101b37750b2124
# good: [46d8bcf485276605669bd17e04f2a5859c8a92de] source-hash-1e1ac3ba37de4aaab3e7fada378ecd73ee2f5b6c
git bisect good 46d8bcf485276605669bd17e04f2a5859c8a92de
# bad: [76aeee20167e39fea13022e37b3901eb9a21f9c3] source-hash-0644a20605965b36fcc983e4c1158820fd858726
git bisect bad 76aeee20167e39fea13022e37b3901eb9a21f9c3
# bad: [a740a696eb4c2c7e2baa3e784d15b4d1156cf90b] source-hash-ae2c256e228b3d4d01e85abdbc797a907c7f6563
git bisect bad a740a696eb4c2c7e2baa3e784d15b4d1156cf90b
Note that this not only affects manipulating pages in page break preview, but will also cause all inserted row breaks to be ignored.
(Insert -> Page Break -> Row Break)
Also, since some time after OpenOffice 3.2.1 but before LO 22.214.171.124, LO introduced another bug, which I'll report shortly. In fit-to-page spreadsheets, page breaks are ignored in spreadsheets where the Height in Pages is set to a large number instead of being left blank. According to the online documentation, "Height in Pages" is the maximum number of pages to be printed vertically stacked. This is a maximum and should not stop manual breaks from functioning as they do when the field is left blank.
We love fit-to-page and use it extensively. Unfortunately, many of our users' documents were created from a custom default template that used fit-to-page with a max of 1 page wide by 1000 pages high.
Because of these two bugs, any time our users open old spreadsheets that require page breaks, LO will simply ignore the breaks until their documents are set to "Reduce/Enlarge."
In summation, the original bug report is about it being impossible to use row breaks while using fit-to-page because 4.1.X's dialog makes it impossible to change "Height in Pages" to blank. I'm adding that row breaks should also be possible when "Height in Pages" is set to an arbitrarily high number.
I tested and can confirm that this behavior (both bugs) is still the same in 126.96.36.199 rc.
It appears that bug 40788 should solve my second issue and it will be available in 4.2.x. I just tested it in the 188.8.131.52 rc, by setting Tools -> Options -> LibreOffice Calc -> Print -> "Always apply manual breaks." This allows fit-to-page to function as it did in OpenOffice 3.2.1 by allowing manual breaks to override a high value for Height in Pages.
Despite your described problem (leaving on of the fields blank did not work) is slightly different from the original problem (manual breaks in Calc do not work for releases newer than 3.2). So I mark this as a duplicate to 40788 which is solved.
*** This bug has been marked as a duplicate of bug 40788 ***
Migrating Whiteboard tags to Keywords: (bibisected)
Remove redundant 'ConfirmedRegression'