Bug 65439

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