Created attachment 80376 [details] Example files (ODT/PDF) and screenshots (PNG) of the various dialogs in question. This appears to be the same issue as originally reported in bug #40618 which has been RESOLVED INVALID. I am raising a new bug report as the version differences may mean this is not necessarily the same issue. I will leave it for the developers to determine this. Problem description: No combination of settings under Tools > Options... > LibreOffice > Print will prevent a warning message about transparency from appearing when exporting to PDF/A-1a, regardless of whether the document has any transparent objects or not. I have tested this under Crunchbang 11 running TDF/LO v4.0.3.3, thus Operating system is set to "Linux (other)" although it may affect all platforms. Steps to reproduce: 1. Open Writer. 2. Insert a single character (e.g., "a"). 3. Save to ODT. 4. Ensure "Transparency" option under the "Printer Warnings" section of the Tools/Option mentioned above is unchecked. 5. Export to PDF/A-1a. 6. "Problems during PDF export" dialogue appears stating "PDF/A forbids transparency. A transparent object was painted opaque instead." 7. PDF is generated as expected. At step (4) I have also tried checking the "Reduce transparency" and "Reduce bitmaps" options and setting the corresponding entries to avoid using / including any kind of transparency, to no effect. I have tried various other setting combinations as well to no effect. Current behavior: At step (6) warning dialogue appears (refer graphic in attached). Expected behavior: Given an appropriate selection of settings at step (6) no warning dialogue should display. Operating System: Linux (Other) Version: 4.0.3.3 release
Related AskLO question: http://ask.libreoffice.org/en/question/15813/why-do-i-always-get-transparency-error-when-i/
I tried to reproduce this with Ubuntu 13.04 and LO 4.1.0.3 but was unable to do so. Owen: Could you please retry with that version if this bug is still valid? http://www.libreoffice.org/download/pre-releases/ Step 5: I use the pdf export from within LO. What do you mean by "export to PDF/A-1a"?
I can reproduce this with Ubuntu 10.04 and LO 4.0.2 and winXp LO 4.1.0.2
(In reply to comment #2) > > Step 5: I use the pdf export from within LO. What do you mean by "export to > PDF/A-1a"? do not use the direct "pdf export" button in the toolbar. use instead "File/Export in PDF Format" than flag the PDF/A-1a option in the right side of the dialog window
Thanks to all for the comments. I am setting to status NEW as a result of comment #3. @James, the problem still persists under v4.0.4.2, however I will try v4.1 as soon as it becomes available later this month. @James and @tommy27, my apologies for not being as clear as I could have been regarding step #5. I am not using the toolbar button (although that will simply use the last settings in any case), but rather: File > Export as PDF... > in the General section I am checking the "PDF/A-1a" option.
(In reply to comment #0) > .... > > Problem description: > No combination of settings under Tools > Options... > LibreOffice > Print > will prevent a warning message about transparency from appearing when > exporting to PDF/A-1a, regardless of whether the document has any > transparent objects or not. basically, LibO shows that warning anytime even if there are no transparent images. we should discover if that is an intended warning that must pop up at any print and if it has always been like that even in previous LibO releases. does anybody have a LibO 3.6.x or 3.5.x version to test?
As a result of comment #6 I have tested a few LO installs here under Ubuntu v10.04 x86_64 (all are x86_64 versions): v3.3.0.4 BuildID: 330m19(Build:6) v3.4.6.2 BuildID: 340m1(Build:602) v3.5.7.2 BuildID: 3215f89-f603614-ab984f2-7348103-1225a5b v3.6.0.4 BuildID: 932b512-69e3009-7a10e5c-fc86223-a55908 v3.6.6.2 BuildID: f969faf-c24b504-8c77064-174276e-40b382 The problem does not occur for v3.5.7.2 or earlier, whereas it is present in v3.6.0.4 and later. I have set the version accordingly to "3.6.0.4. release". Do I need to check the 3.6.0.4 release candidates? Is there any other test I can perform to further assist?
good job Owen, this will help the devs to identify why did this change from 3.5 to 3.6. but as I said, is that warning a bug or an intended alert message that has to be showed anyway? I don't have much experience about that kind of PDF format.
*** Bug 54961 has been marked as a duplicate of this bug. ***
changed SUMMARY to better explain what the bug is about. changed platform to ALL since it affects Windows as well. added keyword REGRESSION since it was not present in LibO 3.5.7... according to previous comments it happered with 3.6.0 and affects all following releases including 4.2.0alpha. basically the transparency warning should not appear if the document has no transparent objects.
>we should discover if that is an intended warning that must pop up at any print >as I said, is that warning a bug or an intended alert message that has to be showed anyway? It would seem to be UX overkill to display a message (warning) regardless of context, but I understand what you mean. If a message does need to be displayed (due to ISO 19005-1:2005 stipulation for example) then I think at the very least the wording should be improved to make clear that it is a required / general warning. The current text can give the impression that there may be a hidden object somewhere in the document that the user is unaware of. My personal preference would be for the warning to be contextual i.e., if transparency is detected then display the message, otherwise avoid displaying the message.
(In reply to comment #11) > .... snip ... > > My personal preference would be for the warning to be contextual i.e., if > transparency is detected then display the message, otherwise avoid > displaying the message. it was contestual in LibO 3.5.7 then it started displaying every time regardless of the presence of transparent object. so the devs should revert the regression, or as you suggested modify the waring text making clearer that it's a default message.
Perhaps same as Bug 59271 ?
Bug #59271 is certainly related although it appears to be an enhancement request to add a new facility for a variety of warning messages. This bug is a regression of prior behaviour and is a clear error in that the warning should not be shown (or the text in the message worded differently for clarity).
Results from bibisect-43all: 9e82321771f66f258d72d9027cbb30598827becf is the first bad commit commit 9e82321771f66f258d72d9027cbb30598827becf Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed May 2 19:14:02 2012 +0200 source-hash-d31997559adac6f03d932cb6c5819149c38c1398 commit d31997559adac6f03d932cb6c5819149c38c1398 Author: Tor Lillqvist <tml@iki.fi> AuthorDate: Sun Apr 15 10:49:41 2012 +0200 Commit: Tor Lillqvist <tml@iki.fi> CommitDate: Sun Apr 15 11:56:53 2012 +0200 Add comphelp and stocservices UNO component mapping # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574 # bad: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15 git bisect bad 8f4aeaad2f65d656328a451154142bb82efa4327 # good: [369369915d3582924b3d01c9b01167268ed38f3b] source-hash-45295f3cdceb4c289553791071b5d7f4962d2ec4 git bisect good 369369915d3582924b3d01c9b01167268ed38f3b # bad: [6fce03a944bf50e90cd31e2d559fe8705ccc993e] source-hash-47e4a33a6405eb1b5186027f55bd9cb99b0c1fe7 git bisect bad 6fce03a944bf50e90cd31e2d559fe8705ccc993e # bad: [8a39227e344637eb7154a10ac825d211e64d584c] source-hash-f5080ebb7022c9f5d7d7fdca4fe9d19f9bb8cabf git bisect bad 8a39227e344637eb7154a10ac825d211e64d584c # bad: [e8bc60acad752e284db73fc4d8ad383ac055361c] source-hash-7e6e16ba6de2d3ef2b130d1ad5ffeabfdb37918e git bisect bad e8bc60acad752e284db73fc4d8ad383ac055361c # good: [19b8950109d519c0dba847f94d5d166044c1db15] source-hash-ff9cca69744b54ca84d98476a9a969d1aa0ff2d3 git bisect good 19b8950109d519c0dba847f94d5d166044c1db15 # good: [c65ac52362b5c5286abebd55d9ba9a8169e0a6aa] source-hash-ad50ae4f3c48a82315f70fff1b9f221e5c74a2da git bisect good c65ac52362b5c5286abebd55d9ba9a8169e0a6aa # bad: [9e82321771f66f258d72d9027cbb30598827becf] source-hash-d31997559adac6f03d932cb6c5819149c38c1398 git bisect bad 9e82321771f66f258d72d9027cbb30598827becf # good: [d34ee3a09f92a227563b358199072404148f7a3a] source-hash-1856186951a70a0bcac4e0c3632ca4afe68c05e3 git bisect good d34ee3a09f92a227563b358199072404148f7a3a # first bad commit: [9e82321771f66f258d72d9027cbb30598827becf] source-hash-d31997559adac6f03d932cb6c5819149c38c1398
Within the above range, this commit looks potentially related: commit f8f96e9da066047d65dad0f4d296171ecef73d43 Author: Andreas Mantke <andi@lappiandreas.site> Date: Sun Apr 15 11:51:37 2012 +0200 Dialog for the option watermark of the PDF export. The dialog for the export to PDF was enhanced with a section for the option of setting a watermark. The dialog has now a special subsection for this with a box to insert a string for the watermark.
Confirmed by building that it was commit f8f96e9da066047d65dad0f4d296171ecef73d43 mentioned above which introduced this change Adding Cc: to maand@gmx.de; Is there any chance you could take a look at this? Thanks
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.