Bug Hunting Session
Bug 80866 - Layout of custom handouts is ignored
Summary: Layout of custom handouts is ignored
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: x86 (IA32) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0 target:5.0.2
Keywords: bibisected, bisected, regression
: 89285 89386 (view as bug list)
Depends on:
Blocks: Print-Dialog Handout-View
  Show dependency treegraph
 
Reported: 2014-07-03 18:32 UTC by hdv.jadev
Modified: 2017-09-24 22:10 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the same file in 4.1 and 4.2.5.2 with a preview of the handout (202.60 KB, image/png)
2014-07-03 18:32 UTC, hdv.jadev
Details
custom handout printing is not possible (96.22 KB, image/png)
2014-09-29 12:19 UTC, Luc Novales
Details
File to demonstrate layout problem (62.46 KB, application/vnd.oasis.opendocument.presentation)
2015-01-06 15:06 UTC, bellgardt
Details
Screenshot where you can see custom layout is ignored (90.77 KB, image/png)
2015-08-14 16:42 UTC, hdv.jadev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description hdv.jadev 2014-07-03 18:32:39 UTC
Created attachment 102213 [details]
Screenshot of the same file in 4.1 and 4.2.5.2 with a preview of the handout

I use Impress a lot and almost always use my own custom layout to print handouts. I used to do this by applying formatting to the handout and then choosing the default option in the print dialog after selecting handout. However it seems this setting no longer respects any custom formatting and just applies the default layout to the handout. It does apply things like added lines etc. But is does not respect the size, position and number of thumbs on a page (see attached screenshot of the same file opened in 4.1 and in 4.2.5.2). This has happened before, so maybe this is a regression of an older bug (I think it was in the last versions of the 3.6 series)?
Comment 1 Cor Nouws 2014-07-05 22:04:37 UTC
Hi Hans,

I see that from 4.2.0 (between alpha1 and rc4) the representations of frames on the view Hand-out are removed. And in Alpha1, already changing those is ignored.

I guess you don't see any frames on that view too in 4.2.5 ??

Further, the new possibilities that you can choose from the Print dialog, they do not match your needs? If so, where pls?

As for a similar issue that should have been fixed before: I don't see it (1).

I do see bug 61607, which basically is the same ?

Cheers,
Cor 


1)  https://bugs.freedesktop.org/buglist.cgi?list_id=441724&short_desc=handout&query_based_on=Impress-Me_on_CC&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&short_desc_type=allwordssubstr&component=Presentation&product=LibreOffice&known_name=Impress-Me_on_CC
Comment 2 hdv.jadev 2014-07-06 12:30:45 UTC
Hi Cor,

I do see the frames in the master and normal view of the handout. It is just that any changes done to them are ignored when printing handouts when you choose the default setting. Normally Impress would then print the handout as you had formatted them, but now it just uses it's own position and size for the slide thumbs.

To recapitulate: previously when yoo chose "handout" in the print dialog and then "default" it would use your own formatting of the handout. Now it does use any additional elements one adds, but it ignores customized size and position for the slide placeholders.

I tried to find out ehen this happened before, but the most accurate time I can find is when we were still in the OpenOffice.org era. When I migrated from 2.4 to 3.x a similar problem arose. The difference is that I seem to remember that then it was not possible to select "default" as a layout".

As far as I understand bug 61607 this is definitely not the same issue. That bug is about remembering state (previously chosen values when printing ranges). This is about ignoring any formaating done to the placeholders in handouts.
Comment 3 Cor Nouws 2014-07-06 21:14:42 UTC
Hi Hans,

(In reply to comment #2)

> I do see the frames in the master and normal view of the handout. It is just
> that any changes done to them are ignored when printing handouts when you
> choose the default setting. Normally Impress would then print the handout as
> you had formatted them, but now it just uses it's own position and size for
> the slide thumbs.

Yep; your initial description was crisp & clear :)

> I tried to find out ehen this happened before, but the most accurate time I
> can find is when we were still in the OpenOffice.org era. When I migrated
> from 2.4 to 3.x a similar problem arose. The difference is that I seem to
> remember that then it was not possible to select "default" as a layout".

I have seen the change in behaviour too. But obviously failed to file the issue.
Probably because I could live with the new offered functions in the Print dialog. 
But - repeating my question in a different form - that does not help you enough??

> As far as I understand bug 61607 this is definitely not the same issue. 

Ah, you are correct. I didn't read that correctly. Thanks for pointing that out.
Cheers,
Cor
Comment 4 hdv.jadev 2014-07-06 21:37:06 UTC
Sadly, not. We have litterally hunderds of Impress files with customized handouts. Printing those with the new way of doing things in Impress is not an option. Look at the screenshot I attached to the original post. You'll see that the slides are larger and are in front of the lines we added to the handout layout. Right now we print using an older version, but as soon as features added to new version will cause problems when opening those files in an older version this won't work anymore. Moreover, why have the option to adjust size and position of the placeholders when it will be ignored later on in the print dialog anyway?
Comment 5 Regina Henschel 2014-07-07 19:40:41 UTC
There had been a chorus of outrage in OpenOffice.org (30 votes and several duplicates), when the custom layout feature had been removed, see https://issues.apache.org/ooo/show_bug.cgi?id=94055. And so it had been added again in OpenOffice.org. LibreOffice should not make the same error.
Comment 6 Cor Nouws 2014-07-07 21:43:02 UTC
(In reply to comment #5)
> ...
> added again in OpenOffice.org. LibreOffice should not make the same error.

Thanks for that Regina,
I'm not sure if it has been removed intentionally though..
Comment 7 Cor Nouws 2014-07-07 21:44:17 UTC
@Rob: any idea if someone deliberately worked on this?
thanks!
Cor
Comment 8 Rob Snelders 2014-07-10 18:25:39 UTC
I don't think anybody is working on this.
Comment 9 Luc Novales 2014-09-29 12:19:39 UTC
Created attachment 107063 [details]
custom handout printing is not possible

I have the same problem with LibreOffice 4.3.1. 

Is there some votation tool to increase bug priority ?

Thanks,
Luc.
Comment 10 Cor Nouws 2014-09-29 13:11:31 UTC
Hi Luc,

(In reply to comment #9)

> Is there some votation tool to increase bug priority ?

Other then working on the code, or get someone you know or pay doing that for you: no..
Comment 11 Bobrazowski 2014-10-13 15:27:11 UTC
I confirm this is a regression, on linux 64 (ubuntu 14.04) 
I suppose this is a bug and not a change because we've been "fighting hard" to have this feature in openoffice and then libreoffice (maybe 4 years ago ?).
Moreover,if the default settings are not taken into account, the handout tab is useless.
kind regards
Comment 12 Joel Madero 2014-10-13 15:45:11 UTC
If you could bibisect that would be great: 
https://wiki.documentfoundation.org/QA/HowToBibisect
Comment 13 Matthew Francis 2014-12-08 03:24:14 UTC
Results from bibisect-43all:

commit 1711ac6e2188f8fed8e027a2241fe878c898a604
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Fri Oct 18 02:26:52 2013 +0000

    source-hash-8a569f1c4decc7440e9dae1af35d7fa59c3b0121
    
    commit 8a569f1c4decc7440e9dae1af35d7fa59c3b0121
    Author:     Miklos Vajna <vmiklos@suse.cz>
    AuthorDate: Thu Aug 22 11:04:15 2013 +0200
    Commit:     Miklos Vajna <vmiklos@suse.cz>
    CommitDate: Thu Aug 22 11:15:02 2013 +0200
    
        SwASCWriter: out of bounds substring access
    
        Regression from 6e0d836ff120ba292ba52f3623a3dd9be04aefc2, when simply
        copy-pasting some string to a terminal window, rFltNm is empty.
    
        Change-Id: I874e262ef1a3ebb38d90d9ef4f1b8d3457c5daff

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
git bisect start 'latest' 'last40onmaster'
# bad: [4360256bc0b1443028a057164fbbdb43847ce68d] source-hash-40543e5321c8f618c125fd6f7f9a24b87431277a
git bisect bad 4360256bc0b1443028a057164fbbdb43847ce68d
# bad: [4360256bc0b1443028a057164fbbdb43847ce68d] source-hash-40543e5321c8f618c125fd6f7f9a24b87431277a
git bisect bad 4360256bc0b1443028a057164fbbdb43847ce68d
# good: [91c3e68c86f5b7143ab0de18c70c46de8314d6e1] source-hash-4e41227dd6af52ec562d10efcb365defba6bd36e
git bisect good 91c3e68c86f5b7143ab0de18c70c46de8314d6e1
# bad: [e33eaf662f84503c8de782d6677d9eb1b0b0d96b] source-hash-6c3d74e8b779b1eb2d9779ed84f1518e078113c4
git bisect bad e33eaf662f84503c8de782d6677d9eb1b0b0d96b
# good: [b39f384b5baf459aa0bd37c20d5886b040293086] source-hash-f0833d965d20594c0f2d74ffca95589a572e012c
git bisect good b39f384b5baf459aa0bd37c20d5886b040293086
# good: [798f42d35a6a87eff9f856f2d3069bdf3112552d] source-hash-5166f28e797aec47a8a48213203ebd6a7ee06302
git bisect good 798f42d35a6a87eff9f856f2d3069bdf3112552d
# bad: [1711ac6e2188f8fed8e027a2241fe878c898a604] source-hash-8a569f1c4decc7440e9dae1af35d7fa59c3b0121
git bisect bad 1711ac6e2188f8fed8e027a2241fe878c898a604
# good: [448f216b427beae48e9019efe0b1265c0bb59722] source-hash-69a0571d6b885cc4771554d22a63170651647f3b
git bisect good 448f216b427beae48e9019efe0b1265c0bb59722
# good: [4ac6bc5a339cb7796d65b043d19fb9b234173aee] source-hash-46575e931479a4e967f2ad6a056b5f4d5490146c
git bisect good 4ac6bc5a339cb7796d65b043d19fb9b234173aee
# good: [d4758f4ff77e4bc7288b08b29aa5a1426d2247bb] source-hash-349c91c8ec6afc1f5c8499529d559af34d115a76
git bisect good d4758f4ff77e4bc7288b08b29aa5a1426d2247bb
# first bad commit: [1711ac6e2188f8fed8e027a2241fe878c898a604] source-hash-8a569f1c4decc7440e9dae1af35d7fa59c3b0121
Comment 14 Matthew Francis 2014-12-08 03:27:43 UTC
Within the range of the bibisect, this commit looks suspicious:

commit a6a04658fb46d9e5ec40438955b777e2eb76b8d2
Author: Jan Holesovsky <kendy@suse.cz>
Date:   Thu Aug 22 09:40:22 2013 +0200

    bnc#835985: When printing handouts using the default, 'Order' did not count.
    
    "Left to right, then down" was the same as "Top to bottom, then right"
    when printing handout; set the 6 pages explicitly as the default.
    
    Change-Id: I4a5f58c8fcf2efdc85ad7bb23bde791c5fb87584



Adding Cc: kendy@collabora.com
Could you possibly have a look at this - perhaps there is a simple solution to this regression for printing handouts with custom layouts in Impress?
Thanks
Comment 15 Matthew Francis 2015-01-04 09:23:34 UTC
Built the tree at the relevant point to check the above - it was indeed commit a6a04658fb46d9e5ec40438955b777e2eb76b8d2 which broke custom handout layouts
Comment 16 bellgardt 2015-01-06 15:06:49 UTC
Created attachment 111855 [details]
File to demonstrate layout problem

The bug still exists in LO 4.3.5.2 in Windows 7,
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5.

In the attached ODP-File a custom layout with 4 slides is used, where the slide areas are bigger than default. When selecting handout default in the printer dialog a 6-slide layout is shown instead. 

In the handout view of the document the 4-slides layout is correctly selected and the custom layout also shown correctly, but this is ignored for printing.

Selecting the 4-slide layout again changes to the default settings and the custom settings are lost.
Comment 17 Cor Nouws 2015-02-10 12:03:55 UTC
*** Bug 89285 has been marked as a duplicate of this bug. ***
Comment 18 Cor Nouws 2015-02-15 11:27:00 UTC
*** Bug 89386 has been marked as a duplicate of this bug. ***
Comment 19 Matthias 2015-08-07 18:56:36 UTC
The bug still exists in 5.0.0.5 on Linux

is there any workaround to make this work?

why is there a handout-tab at all if this handout-feature doesn't work (since years!)?
Comment 20 Joel Madero 2015-08-07 19:00:18 UTC
@Matthias

This is a volunteer based project - things get fixed when a volunteer wants to deal with it...if you're unhappy with the pace of that - you can fix it yourself (the code is readily available) or you can pay for a fix through a certified developer.

For more information see: http://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/

If you're looking for a workaround I suggest going to ask.libreoffice.org or the user mailing list as this is not the appropriate place to seek user advice.
Comment 21 Matthias 2015-08-10 07:16:48 UTC
@Joel: sorry I never wanted to be rude, but this bug exists for a very long time and is very frustrating. It simply looked to me, that this bug was forgotten ...
Comment 22 Commit Notification 2015-08-12 15:18:35 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":

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

tdf#80866: Revert "bnc#835985: When printing ... 'Order' did not count."

It will be available in 5.1.0.

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 23 Commit Notification 2015-08-12 15:18:40 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":

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

tdf#80866, bnc#835985: Better solution to the original bnc# bug.

It will be available in 5.1.0.

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 24 Jan Holesovsky 2015-08-12 16:34:51 UTC
Matthew: Great work bisecting this - thanks so much!

I hope we can consider this fixed now :-)
Comment 25 Taka 2015-08-13 09:42:46 UTC
Has anyone checked the patch really fix the bug?
I cannot find any response on this patch at this moment.
If the fix is only theoretical, changing status to "RESOLVED""FIXED" is too early, I think.
I have a LO 4.3.7. So, I'll check when it come to 4.3.7.
Comment 26 Jan Holesovsky 2015-08-13 10:02:14 UTC
Taka: Would be great if you can download the nightly build containing this fix, and check yourself:

https://wiki.documentfoundation.org/QA/Testing_Daily_Builds

That way you can help the LibreOffice QA team; any asks like "Has anyone checked the patch really fix the bug?" means that you are asking others to do work that you can do yourself, and are a bit offensive.  On the other hand, when you check yourself, lots of people will appreciate it, and will be grateful for your contribution.
Comment 27 Jan Holesovsky 2015-08-13 10:03:28 UTC
[and of course, 4.3.7 is past its end-of-life, there will be no further 4.3.x]
Comment 28 Commit Notification 2015-08-13 10:06:17 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e87f5ca825599c496918c6a890b7a3bac0fbbc2&h=libreoffice-5-0

tdf#80866: Revert "bnc#835985: When printing ... 'Order' did not count."

It will be available in 5.0.2.

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 29 Regina Henschel 2015-08-13 10:51:14 UTC
I have tested it in Version: 5.1.0.0.alpha1+
Build-ID: c614e711136205252ac2c72f9772c718dafc471e
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-08-12_20:36:06
Gebietsschema: de-DE (de_DE)
It is OK in that version.
Comment 30 Commit Notification 2015-08-14 05:01:03 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c59fba2682f01306f3398afeb86f2e3027e011ec&h=libreoffice-5-0

tdf#80866, bnc#835985: Better solution to the original bnc# bug.

It will be available in 5.0.2.

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 31 hdv.jadev 2015-08-14 16:41:13 UTC
I just tried with libreoffice-5-0~2015-08-12_15.36.59_LibreOfficeDev_5.0.2.0.0_Linux_x86_deb.tar.gz, which I downloaded a few minutes ago.

Sadly the problem persists. See attached screenshot. It's a bit small, but you can see 6 thumbs placed over the customized lines. It should be 2 positioned above those lines.

However I strongly suspect I've been too impatient and will have to wait a bit more for the 24-48 hours to pass. Am I correct in that suspicion? 

Anyway, I am really very very very very glad this bug gets some attention! Thanks for that! It is really appreciated very much. This bug is the only reason we have to keep a separate install of 4.1 available on the workstations of our backoffice personnel. That might become a problem if some future incompatibility arises, because we do edit the files in newer versions.
Comment 32 hdv.jadev 2015-08-14 16:42:07 UTC
Created attachment 117918 [details]
Screenshot where you can see custom layout is ignored
Comment 33 Cor Nouws 2015-08-14 18:32:30 UTC
Hi Hans,

(In reply to hdv.jadev from comment #31)

> However I strongly suspect I've been too impatient and will have to wait a
> bit more for the 24-48 hours to pass. Am I correct in that suspicion? 

Could be...
From Help > About LibreOffice copy the Build ID to the end of this 
  http://cgit.freedesktop.org/libreoffice/core/commit/?id=
and you'll get the last included commit. Easy to compare with Kendy's one.

> Anyway, I am really very very very very glad this bug gets some attention!

+1

And thanks for taking effort to test!
Cor
Comment 34 hdv.jadev 2015-08-15 09:52:50 UTC
Hi Cor,

Great tip! Never realized that. I think I just confirmed my suspicion. Well, I'll try again with a newer build when I see it appearing. I'll post the results here.
Comment 35 hdv.jadev 2015-08-15 11:02:52 UTC
I just tested again with the newest build and *YES* it is working just as it should. A great many thanks to all those who worked on this issue!!! This means we can finally start to migrate to a newer version in the office. By the way I do agree that the new text "according to layout" is an improvement. It is easier to understand for non-expert users. I am really glad this has been resolved! Thanks again!
Comment 36 Taka 2015-10-13 11:07:09 UTC
I tested 5.0.2.2 today and find some fixes compared to before,
but I noticed one serious bug unfortunately, where paper size of handout is fixed to letter size irrespective to what is selected in the handout tab.
In short, we cannot change paper size of handout print. 
This bug is more serious than before at least to me.
Does anyone confirm this bug? I reopen this bug anyway.
Comment 37 Cor Nouws 2015-10-13 12:10:02 UTC
Hi Taka,

(In reply to Taka from comment #36)
> I tested 5.0.2.2 today and find some fixes compared to before,
> but I noticed one serious bug unfortunately, where paper size of handout is
> fixed to letter size irrespective to what is selected in the handout tab.
> In short, we cannot change paper size of handout print. 
> This bug is more serious than before at least to me.
> Does anyone confirm this bug? I reopen this bug anyway.

Thanks for writing here!

It is unlikely that your problems come from the same source.
Please try to get more information on printing and all the settings first (if you not already did that). Then if needed file a new bug with step by step description and sample document and so more...
We have great community support in case you want to ask first
  http://www.libreoffice.org/get-help/community-support/

Set this back to fixed.
Regards,
Cor
Comment 38 Robinson Tryon (qubit) 2015-12-17 08:25:03 UTC Comment hidden (obsolete)