Bug 40788 - FORMATTING - Calc ignores manual breaks when "fit to number of pages" is chosen
Summary: FORMATTING - Calc ignores manual breaks when "fit to number of pages" is chosen
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: All All
: highest major
Assignee: Tibby
URL:
Whiteboard: target:4.2.0
Keywords:
: 40613 69584 (view as bug list)
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2011-09-11 10:31 UTC by Karl Behler
Modified: 2017-02-16 17:18 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
just a simple spreadsheet filled with rubbish text. Two row breaks inserted manually. Formatted for A4 landscape printing on 1 (width) x 3 (heigth) pages. (10.71 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-09-11 10:31 UTC, Karl Behler
Details
A table of three courses, participants, and dates. Should be printed on three pages to give a participation list for the three courses. (12.60 KB, application/msword)
2011-09-12 04:39 UTC, Karl Behler
Details
Spreadsheet PDF with 3 Manual Page Breaks OpenOffice 3.2.1 (13.59 KB, application/pdf)
2011-09-12 08:22 UTC, tecknode
Details
PDF print, spreadsheet with 3 Manual Page Brakes, LibreOffice 3.3.4 (13.98 KB, application/pdf)
2011-09-12 08:25 UTC, tecknode
Details
Refurbished version: A table of three courses, participants, and dates. Should be printed on three pages to give a participation list for the three courses. (13.10 KB, application/msword)
2011-09-13 01:46 UTC, Karl Behler
Details
The desired formatting of the Attachment 51101 with StarOffice 9.2 (31.07 KB, application/pdf)
2011-09-13 01:48 UTC, Karl Behler
Details
An undesired unscaled formatting of the attachment 51101 with StarOffice 9.2, showing why it's important to have scaling. (34.69 KB, application/pdf)
2011-09-13 01:50 UTC, Karl Behler
Details
An faulty formatting of the attachment 51101 with LibreOffice 3.5, showing how the not interpreted manual pagebreaks lead to an unusable output. (27.12 KB, application/pdf)
2011-09-13 01:54 UTC, Karl Behler
Details
Detailed analysis of history of this series of bugs and a proposal for a solution. (393.60 KB, application/pdf)
2011-10-11 15:00 UTC, Karl Behler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Behler 2011-09-11 10:31:47 UTC
Created attachment 51054 [details]
just a simple spreadsheet filled with rubbish text. Two row breaks inserted manually. Formatted for A4 landscape printing on 1 (width) x 3 (heigth) pages.

This is a clarification for bugs 34651 and 40613 which probably have all the same cause.

The attached spreadsheet is switched to page break preview mode. The error can easily been demonstrated by choosing "format"/"page"/"sheet" and then switching between "Reduce/enlarge printout 100%" (which is the current setting when opening the sheet) and "Fit print range to width/heigth" or "... number of pages" with pages 3.

The manual breaks in both cases are ignored and the formatting engine does it's own page breaks.

This error is not present in StarOffice 9.2 (Suse 11.2, Suse 11.4, Solaris SPARC, Solaris X86).
This error is reproducible under LibreOffice 3.3.2 and 3.5.0 (own build) on Suse 11.4.
I guess it's hardware and OS independant, but I only checked the combinations given above.
Comment 1 Rainer Bielefeld Retired 2011-09-11 23:32:03 UTC
@Karl Behler:
You expect the manual breaks to be respected also for Menu 
'Format -> Page -> Scale -> Scaling mode -> Fit print range(s) on number of pages' 
and 
'Format -> Page -> Scale -> Scaling mode -> Fit print range(s) to width/height'?
Comment 2 Karl Behler 2011-09-12 01:46:04 UTC
(In reply to comment #1)
> @Karl Behler:
> You expect the manual breaks to be respected also for Menu 
> 'Format -> Page -> Scale -> Scaling mode -> Fit print range(s) on number of
> pages' 
> and 
> 'Format -> Page -> Scale -> Scaling mode -> Fit print range(s) to
> width/height'?

Yes, that's what I expect and that's the way it worked as long as StarOffice/OpenOffice was developed under Sun's management. (Until Release 9.2)
(I luckily still have an old release at hand and so I'm able to revert back when formatting my tables.)

Why? 
If I'm setting something manually it should have precedence over anything automatic. If it's not in direct contradiction.
The format setting is a scaling method. It's not obvious what it means to page breaking. And it's easy to apply both rules accordingly.
So why was it changed from release 3.2 to 3.3???
Only because exel is doing this the wrong way as well?
Why not doing things better than MS?

I will upload another more carefully designed sheet, which will makes it more obvious why this is an important feature.
Comment 3 Rainer Bielefeld Retired 2011-09-12 02:16:41 UTC
I found to old OOo specifications on <http://specs.openoffice.org/calc/index.html>, none of them helps to find out what might have been intended behavior. Also Help and documentation do not clarify priority.

The new behavior is intended, please see mentioned OOo bug No 54993. I agree with intentions of that fix. 

@Karl Behler
If you can contribute a conclusive, well founded user scenario what establishes need for respecting manual page breaks for those printer settings (I can't imagine any) please file a new Bug as Enhancement Request.
Comment 4 Rainer Bielefeld Retired 2011-09-12 02:38:42 UTC
*** Bug 40613 has been marked as a duplicate of this bug. ***
Comment 5 Rainer Bielefeld Retired 2011-09-12 02:47:29 UTC
@David:
I believe Help and documentation should explain priorities of various settings more elaborated. Can you handle that?
Comment 6 David Nelson 2011-09-12 04:30:21 UTC
@Rainer: Bookmarked for attention and forwarded to the docs team mailing list.
Comment 7 Karl Behler 2011-09-12 04:39:48 UTC
Created attachment 51067 [details]
A table of three courses, participants, and dates. Should be printed on three pages to give a participation list for the three courses. 

This attachment shows why it makes sense to give manual row breaks precedence above automatic page breaks done according to the scaling to a certain number of pages.

The spreadsheet scenario is a list of participants which attend three different courses. Finally you want to have a participants/participation printout for each course e.g. for bookkeeping in the course itself.
So you say the formatted output should be three pages high and one page wide.
Now you sort the list of participants after the number of the course they attend.
Finally you insert a manual row break after the first and second block of participants. Printing this with the given scaling law gives always three pages each course on a separate page. (That's how it was in StarOffice from release 8.0 to 9.2 which is in fact a couple of years! And it was the same in OOO too.)

To achieve the same with the percentage enlarge/reduce scaling law is only possible by adjusting the enlargement factor iteratively until the sheet fits on the desired number of pages. Adding a column or changing a column width in your table may require a new adjustment. Which is annoying.

Sorry, this is not a request for enhancement, but a request to revert back to a feature, which we already had, but is now lost. No matter what other bugs say about this.
Comment 8 Rainer Bielefeld Retired 2011-09-12 05:26:04 UTC
Karl Behler:
Can you please explain really referring to your sample document? 
Course is the same as "Series"?
Before we discuss whether "bug or not a bug" it must be free of doubt what your goal is.
Currently  I still am not sure whether I understand your explications correctly.

I believe it would help if you could add some explication like:

I need 
- 3 printouts from Document "Sheet1", each on a separate paper sheet, each with heading A1:L10
 -- A2:L7
 -- A8:L15
 -- A16:l19
  I expect the formatting ...   (to fill complete page width/height, ... ?)
- 1 print, showing complete A1:L19 on 1 paper sheet
  what should be created easily without many modifications in settings

Or similar?
Comment 9 Karl Behler 2011-09-12 07:11:53 UTC
(In reply to comment #8)
> Karl Behler:
> Can you please explain really referring to your sample document? 
> Course is the same as "Series"?
Yes. Course is a series of lectures held e.g. over ten weeks one hour a week.
Course 1 (lecture series 1) runs on Mondays.
Course 2 (lecture series 2) runs on Tuesdays.
etc.
What I need is three sheets of paper. 1st containing participants of course 1, 2nd ...., 3rd ...
What I don't need is e.g. 6 sheets of paper, first three showing columns A:K and second three showing column L.
What I also don't need is e.g. two sheets of paper containing participants of course 1, 2, and 3 on page one and then a new header and the last participant of course three on page 2.
You can try out all this by looking at the page break preview and changing the sheet scaling parameters in the Format -> Page menu.

So I have to scale the page width so that the whole number of columns fits onto one page. A:L -> page width 1
After that I have to distribute the rows over three pages so that all participants for course one appear on the first page, course 2 second page, course 3 third page.
Of course there is a repeating header which in this example consists of rows 1:2. And of course all courses have a differing number of participants. (It's no option to introduce empty lines.) 
So I ask to format the output height over three pages.
However the break between the pages has to be exactly between participants of course 1 and 2 and between participants of course 2 and 3.

I will attach some finally formatted examples as PDFs, but first I have to start my lectures in real live. I'm still using StarOffice 9.2 for that.

So thanks for the moment. I will come back.

Karl

> Before we discuss whether "bug or not a bug" it must be free of doubt what your
> goal is.
> Currently  I still am not sure whether I understand your explications
> correctly.
> 
> I believe it would help if you could add some explication like:
> 
> I need 
> - 3 printouts from Document "Sheet1", each on a separate paper sheet, each with
> heading A1:L10
>  -- A2:L7
>  -- A8:L15
>  -- A16:l19
>   I expect the formatting ...   (to fill complete page width/height, ... ?)
> - 1 print, showing complete A1:L19 on 1 paper sheet
>   what should be created easily without many modifications in settings
> 
> Or similar?
Comment 10 Rainer Bielefeld Retired 2011-09-12 07:19:52 UTC
bugzilla-daemon@freedesktop.org schrieb:

> What I need is three sheets of paper. 1st containing participants of course 1,
> 2nd ...., 3rd ...

Hi,

now I understand the core of the problem, I will do further 
investigations tomorrow.

Thank you for your patience

Rainer Bielefeld
Comment 11 tecknode 2011-09-12 08:22:17 UTC
Created attachment 51077 [details]
Spreadsheet PDF with 3 Manual Page Breaks OpenOffice 3.2.1

This is how my spreadsheet SHOULD PRINT.

(OpenOffice 3.2.1, Sheet set "Width in pages" = 1, "Height in pages =5")
Comment 12 tecknode 2011-09-12 08:25:19 UTC
Created attachment 51078 [details]
PDF print, spreadsheet with 3 Manual Page Brakes, LibreOffice 3.3.4

This is the PDF printout using LibreOffice 3.3.4 release, which is wrong.

(LibreOffice 3.3.4, Sheet set "Width in pages" = 1, "Height in pages =5")
Comment 13 Karl Behler 2011-09-13 01:46:16 UTC
Created attachment 51101 [details]
Refurbished version: A table of three courses, participants, and dates. Should be printed on three pages to give a participation list for the three courses.
Comment 14 Karl Behler 2011-09-13 01:48:07 UTC
Created attachment 51102 [details]
The desired formatting of the Attachment 51101 [details] with StarOffice 9.2
Comment 15 Karl Behler 2011-09-13 01:50:18 UTC
Created attachment 51103 [details]
An undesired unscaled formatting of the attachment 51101 [details] with StarOffice 9.2, showing why it's important to have scaling.
Comment 16 Karl Behler 2011-09-13 01:54:57 UTC
Created attachment 51104 [details]
An faulty formatting of the attachment 51101 [details] with LibreOffice 3.5, showing how the not interpreted manual pagebreaks lead to an unusable output.
Comment 17 Karl Behler 2011-09-13 04:00:25 UTC
(In reply to comment #10)
> bugzilla-daemon@freedesktop.org schrieb:
> now I understand the core of the problem, I will do further 
> investigations tomorrow.
> 
> Thank you for your patience
> 
> Rainer Bielefeld

Hello Rainer,

in the meantime I've updated my example spreadsheet so that I hope my intention becomes clearer. I also added three PDFs showing the various formattings possible, but only one makes sense and that formatting does not work anymore with newer releases.

Hope, this helps.

Karl
Comment 18 Rainer Bielefeld Retired 2011-09-13 04:52:20 UTC
@Karl Behler
It's known what you want, a solution will be discussed on 
<libreoffice-ux-advise@lists.freedesktop.org>
Comment 19 Rainer Bielefeld Retired 2011-09-28 01:33:02 UTC
@Karl Behler
Unfortunately nobody answered to my questions on the mailing lists.
I can understand that automatic page breaks will be ignored, but the reason to ignore manually inserted breaks is difficult to understand.

@Kohei:
Can you remember or imagine why the behavior has been modified? There might have been good reasons, but reporter's arguments in comment 17 also are good, and I find no way to fulfill his needs with the current behavior.
Comment 20 Karl Behler 2011-09-28 15:52:27 UTC
Rainer,

I meanwhile analysed the history of this bug back to the first design 
document (thanks to your reference to it) > --- Comment #3 from Rainer 
Bielefeld <LibreOffice@bielefeldundbuss.de> 2011-09-12 02:16:41 PDT ---
> I found to old OOo specifications on
> <http://specs.openoffice.org/calc/index.html>, none of them helps to find out
> what might have been intended behavior. Also Help and documentation do not
> clarify priority.
>
> The new behavior is intended, please see mentioned OOo bug No 54993. I agree
> with intentions of that fix.
and further on to a couple of filed bugs together with the attached 
sample documents.
In my opinion the last change should be reverted and the old behaviour 
which was valid until release 3.2 should be reinstalled. Since at least 
one of the sample documents has a logical error, which was wrongly 
analysed and led to a false conclusion.
I would like it very much if we could leave this bug open until I have 
the opportunity to make the results of my analysis completely clear. 
It's a bit complicated and I will need more time to write it down.
(It also needs a description why the old behaviour is important and why 
here LibreOffice should behave better than Excel does.)

Regards,
Karl

Am 28.09.2011 10:33, schrieb bugzilla-daemon@freedesktop.org:
> https://bugs.freedesktop.org/show_bug.cgi?id=40788
>
> Rainer Bielefeld<LibreOffice@bielefeldundbuss.de>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |kohei.yoshida@gmail.com
>
> --- Comment #19 from Rainer Bielefeld<LibreOffice@bielefeldundbuss.de>  2011-09-28 01:33:02 PDT ---
> @Karl Behler
> Unfortunately nobody answered to my questions on the mailing lists.
> I can understand that automatic page breaks will be ignored, but the reason to
> ignore manually inserted breaks is difficult to understand.
>
> @Kohei:
> Can you remember or imagine why the behavior has been modified? There might
> have been good reasons, but reporter's arguments in comment 17 also are good,
> and I find no way to fulfill his needs with the current behavior.
>
Comment 21 Karl Behler 2011-10-11 14:48:07 UTC
Hello Rainer,

this is the result of my analysis of the "fit the x/y pages" story.
>> It's a bit complicated and I will need more time to write it down.
>> (It also needs a description why the old behaviour is important and why
>> here LibreOffice should behave better than Excel does.)
I'm sorry, it has become a complicated document and so I decided to
write it as a three pages ODT/PDF document, but it's important to review
the whole story and to look at the Excel comparison.
In fact Excel handles user mistakes in this case very clever.

I simultaneouly send this mail to
libreoffice-ux-advise@lists.freedesktop.org.
May be it triggers a discussion now.

Best regards,

Karl
Comment 22 Karl Behler 2011-10-11 15:00:16 UTC
Created attachment 52240 [details]
Detailed analysis of history of this series of bugs and a proposal for a solution.
Comment 23 Rainer Bielefeld Retired 2011-10-12 01:52:43 UTC
I nearby never print from Spreadsheet, so my experience is small, but for my needs with reporter's sample OOo-dev 3.2.1 fulfills my experiences, LibO 3.4 does not. I did not think too much about all arguments and facts in "detailed analysis", but after a quick reading I agree with the thoughts and with the conclusion that for particular user need the current behavior is a step back. I still have difficulties to find a user scenario founding the step from OOo 3.2 to LibO's behavior.

@Karl:
Brilliant! I agree with your thoughts 
- "2008-10-06 Kohei filed a proposal issues.apache.org/ooo#94698 ...".
- I agree with your disagree concerning "duplicate of 54993" for 
  pache.org/ooo#94698.

I still see only user scenarios funding your opinion.

@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 24 tecknode 2011-10-12 05:23:43 UTC
(In reply to comment #22)
> Created an attachment (id=52240) [details]
> etailed analysis of history of this series of bugs and a proposal for a
> solution.

OK, read your PDF.

One thing seems missing. In the current version of LibO, if print-scaling option Page-Width x Pages-High does NOT work (Manual Row Breaks ignored) what print-scaling options DO work?

In my example spreadsheet (first 2 PDF prints in attachments) I want the spreadsheet to print WITH my Manual Page Breaks, one page wide.
Comment 25 Karl Behler 2011-10-13 06:47:08 UTC
@tecknode

Manual breaks are *NOT* ignored in the normal Reduce/Enlarge mode! 
So my way to get a properly scaled printout *with manual breaks* is
- first to change view to "Page Break Preview" and
- then to choose from Format -> Page -> Sheet -> Scale, Scaling Mode -> 
                                 Reduce/Enlarge Printout by scaling factor.
Iteratively adjust the scaling factor until your printout is one page wide.
(The new scaling factor is applied when you click OK in the Format-Page sub-window. To change the factor again, you need to reopen the Format-Page windows again.)
Finally control the output before printing by choosing Print Preview from the File menu.

Thanks for your insisting, because the method just described demonstrates the benefit of the fit to x/y pages scaling mode.
Comment 26 tecknode 2011-10-14 05:22:20 UTC
(In reply to comment #25)
> @tecknode
> 
> Manual breaks are *NOT* ignored in the normal Reduce/Enlarge mode! 
> So my way to get a properly scaled printout *with manual breaks* is
> - first to change view to "Page Break Preview" and
> - then to choose from Format -> Page -> Sheet -> Scale, Scaling Mode -> 
>                                  Reduce/Enlarge Printout by scaling factor.
> Iteratively adjust the scaling factor until your printout is one page wide.
> (The new scaling factor is applied when you click OK in the Format-Page
> sub-window. To change the factor again, you need to reopen the Format-Page
> windows again.)
> Finally control the output before printing by choosing Print Preview from the
> File menu.
> 
> Thanks for your insisting, because the method just described demonstrates the
> benefit of the fit to x/y pages scaling mode.

Thanks.

But I am not sure what you mean in your last sentence.

I read it as you agreeing that LibO Calc SHOULD print Manual Row Breaks using the "x/y pages scaling mode" (without changing scaling factor) which means LibO should be changed to confirm.

The method you describe is a long work-around.  Especially since OO 3.2 DOSE work with "x/y" pages set which means it was done in the past and *newer versions broke it*.
Comment 27 Karl Behler 2011-10-14 08:33:34 UTC
> The method you describe is a long work-around. Especially since OO 3.2 DOES
> work with "x/y" pages set, which means it was done in the past and *newer
> versions broke it*.

Exactly that's what I thought.
Comment 28 Charles 2012-03-01 11:58:13 UTC
I just smashed headlong into this bug, and am confused by reading the comments...

I sure hope I'm reading them wrong - is someone seriously suggesting that the current behavior of ignoring explicitly set row-breaks is intended or even desired behavior?

If I tell Calc that I want the spreadsheet printed exactly one page wide, and leave the length field blank (meaning as many pages as necessary), but have set one or more row breaks, I expect Calc to do exactly what I told it to. I know this didn't used to be a problem, but I haven't apparently needed to do this in a while. I though I was going crazy, until I decided to google and found this bug...
Comment 29 Michael Stahl (CIB) 2012-07-11 10:24:00 UTC
it's a bit confusing and the reporter seems to argue it's a regression,
setting the keyword so it gets some attention.
Comment 30 Kohei Yoshida 2012-07-11 15:40:10 UTC
It's not a regression.  Despite heated disagreement on this, technically it's not a regression so let's stay true to that.
Comment 31 Norbert Scheibner 2012-07-18 22:57:35 UTC
(In reply to comment #30)
> It's not a regression.  Despite heated disagreement on this, technically it's
> not a regression so let's stay true to that.

If it worked as expected and documented in a former version, isn't that called a regression, if it's broken now? The actual behavior doesn't even bring us a new feature or is in any way a consistent.

I use spreadsheets the same way, Karl does and it got me stuck with OOo 3.2.1 too.
Comment 32 Joel Madero 2013-02-13 17:13:17 UTC
Because this has (in the past) gotten so much attention, I am going to move this to 3.6 MAB.

3.5 is at the end of its life cycle and therefore will not be developed any further. Because of this we are closing the 3.5 MAB meta tracker. 

Personally I don't think that this is a MAB as it's very specific and only an annoyance (doesn't prevent high quality work, just have to do a workaround of having different sheets instead of page breaks in this particular fashion). Furthermore it's been on the list for a long time and doesn't seem to have many users affected, almost all comments are developers, QA and Karl (reporter).
Comment 34 tommy27 2013-08-16 13:36:28 UTC
is there anybody still experiencing this bug with recent LibO 4.0.4 or 4.1.0 releases?
Comment 35 ron gregor 2013-08-16 14:18:38 UTC
I did confirm that this bug does exist in 4.0.4.2.

I would also like to add that instead of debating whether the manual page breaks should be honored as past versions have or should not be honored to be compatible with other programs why not put a simple check box when using scaling by page "use manual page break when scaling". No more debate - the user can choose - making LibreOffice the better program to use in this case. And the argument saying that honoring the manual page breaks is not possible (as I have seen on some postings) doesn't seem correct when the older version used to do just that.
Comment 36 tommy27 2013-08-16 14:26:49 UTC
according to previous comment I move this report from mab3.6 list to mab4.0 list since 3.6.x is EOL.
Comment 37 tecknode 2013-08-16 15:28:20 UTC
(In reply to comment #34)
> is there anybody still experiencing this bug with recent LibO 4.0.4 or 4.1.0
> releases?

YES.  Behavior is still having to use percent setting for Manual Row Breaks to work properly.

The use of "Fit print range(s) to width/height" or "Fit print range(s) on number of pages" ignores Manual Row Breaks.....UNLESS....

Just discovered that if your document print-range (both width and height) is larger than the print paper the use of "Fit print range(s) to width/height" DOES work properly with Manual Row Breaks.

The problem presently is the print is NOT being AUTOMATICALLY scaled to fit your criteria.


What needs to be done is change "Fit print range(s) on number of pages" to
"Fit print range(s) on number of pages (width/height)" that is: print on [# pages wide] and [# pages high] and AUTOMATICALLY scale as necessary.
Comment 38 Norbert Scheibner 2013-08-16 19:45:54 UTC
(In reply to comment #37)
>
> Just discovered that if your document print-range (both width and height) is
> larger than the print paper the use of "Fit print range(s) to width/height"
> DOES work properly with Manual Row Breaks.

How did U do this? I could not reproduce that.
I filled A1 to K100 with random numbers in font size 26 and could not bring LibO 4.1 under any circumstances to honor manually set page breaks in line 7 and/or row E for instance.
Comment 39 Tibby 2013-10-15 11:50:21 UTC
So, I'm currently working on this problem - working on 3.6 branch but upstreaming later this week. So far, I've added a checkbox option under Tools - Options - Calc - Print to force manual breaks.

However, this bug: https://issues.apache.org/ooo/show_bug.cgi?id=54993 (which the current behaviour LO was introduced to fix, as well as for MSO interop) rears its head when the number of pages or height/width specified in the scaling settings conflicts with the manual breaks in the document - i.e. what if 1 row break is specified (so the document will be 2 pages at least) and scaling setting is to fit to 1 page? The scaling function can't converge due to the conflict, so it bottoms out at the minimum zoom size.

What I really need now is feedback on what the most sensible way of handling this situation would be.
- Breaks can be forced anyway, ignoring the scale settings - assuming 100% scale, perhaps? Or scale so the number of pages == the number of breaks + 1.
- We could revert to the current behaviour and ignore breaks.
- The UI could be adapted to handle this more gracefully, e.g. putting minimum bounds on # of pages when the force breaks option is selected, or disabling the force breaks option if it'll cause a conflict. Doesn't account for import of malformed documents though.

Or maybe something else. Any ideas from anyone who uses the functionality affected by this bug?
Comment 40 tecknode 2013-10-15 16:51:35 UTC
On Tue, 15 Oct 2013 11:50:21 +0000, you wrote:

Q> https://bugs.freedesktop.org/show_bug.cgi?id=40788
Q> 
Q> Tibby <tibbylickle+fdb@gmail.com> changed:
Q> 
Q>            What    |Removed                     |Added
Q> ----------------------------------------------------------------------------
Q>              Status|NEW                         |ASSIGNED
Q>            Assignee|libreoffice-bugs@lists.free |tibbylickle+fdb@gmail.com
Q>                    |desktop.org                 |
Q> 
Q> --- Comment #39 from Tibby <tibbylickle+fdb@gmail.com> ---
Q> So, I'm currently working on this problem - working on 3.6 branch but
Q> upstreaming later this week. So far, I've added a checkbox option under Tools -
Q> Options - Calc - Print to force manual breaks.
Q> 
Q> However, this bug: https://issues.apache.org/ooo/show_bug.cgi?id=54993 (which
Q> the current behaviour LO was introduced to fix, as well as for MSO interop)
Q> rears its head when the number of pages or height/width specified in the
Q> scaling settings conflicts with the manual breaks in the document - i.e. what
Q> if 1 row break is specified (so the document will be 2 pages at least) and
Q> scaling setting is to fit to 1 page? The scaling function can't converge due to
Q> the conflict, so it bottoms out at the minimum zoom size.
Q> 
Q> What I really need now is feedback on what the most sensible way of handling
Q> this situation would be.
Q> - Breaks can be forced anyway, ignoring the scale settings - assuming 100%
Q> scale, perhaps? Or scale so the number of pages == the number of breaks + 1.
Q> - We could revert to the current behaviour and ignore breaks.
Q> - The UI could be adapted to handle this more gracefully, e.g. putting minimum
Q> bounds on # of pages when the force breaks option is selected, or disabling the
Q> force breaks option if it'll cause a conflict. Doesn't account for import of
Q> malformed documents though.
Q> 
Q> Or maybe something else. Any ideas from anyone who uses the functionality
Q> affected by this bug?


Note that this errant behavior did NOT occur with OpenOffice 2.2, only
appeared with OpenOffice 2.4 and LibreOffice.  So has anyone bothered
to go back and look at the older code?

What SHOULD happen when you choose pint to x-pages-wide +
x-pages-high, OR x pages, print *scaling should be automatic* so the
print fits what the user specified WITH manual row breaks.

As of now manual breaks only work if you scale the print below 100%.
Comment 41 Tibby 2013-10-15 17:48:54 UTC
(In reply to comment #40)
> On Tue, 15 Oct 2013 11:50:21 +0000, you wrote:
> Note that this errant behavior did NOT occur with OpenOffice 2.2, only
> appeared with OpenOffice 2.4 and LibreOffice.  So has anyone bothered
> to go back and look at the older code?

Yes. It's a really trivial fix + additional config option. Literally an if statement surrounds a small block of code.

> 
> What SHOULD happen when you choose pint to x-pages-wide +
> x-pages-high, OR x pages, print *scaling should be automatic* so the
> print fits what the user specified WITH manual row breaks.
> 
> As of now manual breaks only work if you scale the print below 100%.

Yes, that's fine. But I'm talking specifically about the corner case where you have manual breaks that cause the content to display over *more* pages than specified in the scaling. Another example - two row breaks in a document imply that at least *three* pages are needed (the first page, the page after the first row break and the page after the second break). Now, what happens when we tell LO to fit that print range to *two* pages? Or rather, what *should* happen? At least one row break would have to be ignored to make that happen, or the "to pages" value has to be ignored.
Comment 42 m.a.riosv 2013-10-15 19:13:16 UTC
(In reply to comment #41)

> Yes, that's fine. But I'm talking specifically about the corner case where
> you have manual breaks that cause the content to display over *more* pages
> than specified in the scaling. 

IMHO, maybe the better, an option beside scales to disable manual page breaks, if this it is not so easy to implement, then must be user controlling the situation with mix between the manual breaks and page print options, the issue is for now that there is no choice.
Comment 43 Commit Notification 2013-11-04 15:56:53 UTC
Eilidh McAdam committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7e4f8eb5eff642c7fc8bfa665289d55a1c5b054b

fdo#40788: Allow manual breaks in Calc to be forced



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 44 Eike Rathke 2013-11-04 15:57:47 UTC
Also needed to make this work with some cases of misfits is http://cgit.freedesktop.org/libreoffice/core/commit/?id=a37092075791ccbe6081e3e01990df6d9e6cdce6
Comment 45 ron gregor 2013-11-05 14:48:19 UTC
I downloaded the daily 4.2.0 and tested this and the bug is NOT fixed.

I have a file that we use manual breaks to make it 5 sheets. When I set the fit to pages width / height to 1 wide and 5 high (or higher) the manual breaks are not used and it comes out on 4 pages. We us this so the print range is reduce to fit the width of the page and the manual breaks keeps what we print on the pages grouped in an organized manner. We have a summary page and then the detail pages are list for 5 days (currently 2 days fit entirely on a page). We want to make sure that no day is split over 2 pages so we use a manual break. 

This fix does work when the reduce /enlarge page percentage is used Thanks for that much. The bug is however called : Calc ignores manual breaks when "fit to number of pages" is chosen. When using fit to number of pages or fit to width/height is used the bug still exists.

Thanks - Ron
Comment 46 Tibby 2013-11-05 15:15:23 UTC
(In reply to comment #45)
> I downloaded the daily 4.2.0 and tested this and the bug is NOT fixed.
> 
> I have a file that we use manual breaks to make it 5 sheets. When I set the
> fit to pages width / height to 1 wide and 5 high (or higher) the manual
> breaks are not used and it comes out on 4 pages. We us this so the print
> range is reduce to fit the width of the page and the manual breaks keeps
> what we print on the pages grouped in an organized manner. We have a summary
> page and then the detail pages are list for 5 days (currently 2 days fit
> entirely on a page). We want to make sure that no day is split over 2 pages
> so we use a manual break. 

Did you check the option Tools -> Options -> LibreOffice Calc -> Print -> "Always apply manual breaks"? I tried with a document similar to what you described at it worked as expected with that option switched on - i.e. shrunk to fit horizontally but over 5 pages due to breaks.

> This fix does work when the reduce /enlarge page percentage is used Thanks
> for that much. The bug is however called : Calc ignores manual breaks when
> "fit to number of pages" is chosen. When using fit to number of pages or fit
> to width/height is used the bug still exists.

The fix shouldn't change any behaviour for the reduce/enlarge by percentage scale option. That option already worked with manual breaks.

If the option is switched on and you still can't see breaks, please attach a document to test against.
Comment 47 ron gregor 2013-11-05 16:32:25 UTC
First THANKS to all you worked on this bug. It is FIXED.

Sorry about changing the status to soon I am usually more thorough to make sure I have properly check things out.

I did miss the need to set an option in the main options area. This does work and is greatly appreciated. This may be better used as an option to turn on / off in the page setup when a " fit to" option is being used. This way it can be turned on /off as needed or would this create a non-standard spreadsheet setting?

Thanks again for all the great work - Ron
Comment 48 Tibby 2013-11-05 17:09:05 UTC
(In reply to comment #47)
> First THANKS to all you worked on this bug. It is FIXED.
> 
> Sorry about changing the status to soon I am usually more thorough to make
> sure I have properly check things out.
> 
> I did miss the need to set an option in the main options area. This does
> work and is greatly appreciated. This may be better used as an option to
> turn on / off in the page setup when a " fit to" option is being used. This
> way it can be turned on /off as needed or would this create a non-standard
> spreadsheet setting?
> 
> Thanks again for all the great work - Ron

No problem :) I (and others) agree that the option would fit better with the other scaling options. However, as you point out, it changes the type of setting it is and would really come down to making a change/addition to ODF. That generally takes some time and energy, so I'll see what I have time for. It would be a better solution in the long term though.
Comment 49 m.a.riosv 2013-11-06 02:44:50 UTC
Thanks Eilidh, great see this issue solved.

Can be ported in 4.1?
Comment 50 stragu 2014-02-12 08:04:25 UTC
Moving to mab4.1 (Bug 60270) because:
- 4.0 reached EOL (End Of Life)
- bug confirmed in later version
Comment 51 sophie 2014-02-12 09:34:53 UTC
Changing importance to reflect the new policy - Sophie
Comment 52 tommy27 2014-05-13 04:33:47 UTC
please retest against 4.2.4.2
if issue is still there please move it to mab4.2 list since 4.1.x is END OF LIFE
Comment 53 Eike Rathke 2014-05-13 08:31:06 UTC
The original problem actually is fixed. Tibby reopened it again to move the option to some more intuitive place in the dialogs. However, I suggest to close this bug as fixed (which I do now) and open a new one (which I don't ;-) for the remaining work of getting the option into document specific settings.
Comment 54 Karl Behler 2014-05-13 09:06:33 UTC
Hi everybody,

it's great to hear about progress on this bug.
I will checkout latest LibreOffice release soon and see how it looks like.

Karl
Comment 55 m.a.riosv 2014-05-13 12:12:05 UTC
Verified for the three scale options with:
Win7x64Ultimate:
Version: 4.2.3.3 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0
Versión: 4.2.4.2 Id. de compilación: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Version: 4.2.5.0.0+ Build ID: c4e10ad83fe1fa92a115327c1909218f5dc8c8bd
   TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-05-12_10:29:35


But doesn't work for me with:
Version: 4.3.0.0.alpha1+ Build ID: 224b235971a01971de626d38ccc8506d0a55771b
   TinderBox: Win-x86@39, Branch:master, Time: 2014-05-11_23:55:17
Comment 56 Joel Madero 2014-05-13 15:02:45 UTC
Please do not reopen a bug when an experienced developer says don't. Report a new bug thanks
Comment 57 Karl Behler 2014-05-19 12:36:07 UTC
*** Bug 40613 has been marked as a duplicate of this bug. ***
Comment 58 Karl Behler 2014-05-19 13:27:18 UTC
*** Bug 69584 has been marked as a duplicate of this bug. ***
Comment 59 Dave Nadler 2017-02-16 17:06:36 UTC
This is still broken in version 5.2.5.1

If I change the page to not "shrink to fit pages width/length",
then I can update the page breaks and things work as expected.

But, with scaling to fit specified pages, dragging page breaks
in "View Pagebreaks" does not work... And add delete page
breaks silently fails without explanation.

Thanks,
Best Regards,Dave
Comment 60 tommy27 2017-02-16 17:18:51 UTC
(In reply to Joel Madero from comment #56)
> Please do not reopen a bug when an experienced developer says don't. Report
> a new bug thanks

as already said before, don't do that.
open a new bug a put this under "see also".