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)?
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
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.
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
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?
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.
(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..
@Rob: any idea if someone deliberately worked on this? thanks! Cor
I don't think anybody is working on this.
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.
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..
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
If you could bibisect that would be great: https://wiki.documentfoundation.org/QA/HowToBibisect
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
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
Built the tree at the relevant point to check the above - it was indeed commit a6a04658fb46d9e5ec40438955b777e2eb76b8d2 which broke custom handout layouts
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.
*** Bug 89285 has been marked as a duplicate of this bug. ***
*** Bug 89386 has been marked as a duplicate of this bug. ***
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!)?
@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.
@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 ...
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.
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.
Matthew: Great work bisecting this - thanks so much! I hope we can consider this fixed now :-)
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.
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.
[and of course, 4.3.7 is past its end-of-life, there will be no further 4.3.x]
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.
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.
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.
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.
Created attachment 117918 [details] Screenshot where you can see custom layout is ignored
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
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.
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!
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.
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
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]