Created attachment 106808 [details] Exampled document with various frame-backgrounds Frame-backgrounds don't match the visible presentation in Writer and the exported PDF. The attached document with its exported PDFs shows the problem.
Created attachment 106810 [details] With 4.2.6.3 exported PDF
Created attachment 106811 [details] With 4.3.2.2 exported PDF
Hi Rico, thanks for filing this issue. And for the nice text document. I can confirm this problem (on Ubuntu 32 bits) Would it be possible for you to write out the specific combinations / settings that have a problem :) ? Would be great! I see that it is OK in LibreOffice 3.3.4 Do you know have any idea up to when this was OK? In any case, a regression. Cheers, Cor
Ah, now I see your 4.2.6 attachment with correct output. Sorry! Checking in 4.3.0 alpha1 and 4.3.0 beta 2, rc1 and rc3 ... various kinds of wrong rendering of the frames in Writer Ughh 4.3.0.4 is the first version that I have that gives the problem. I don't have 4.3.0.3 to test. Bibisectrequest needed. NOTE: looking at wrong rendering in early 4.3.0 versions, there is more around this probably...
Created attachment 107587 [details] PDFs generated during bibisection Hi, thank you for nice testcase! It seems, that bug 83963 is a specific case of your report. I did a bibisection with following result: pushkin@pushkin-VBX:~/LO_bug/bibisect-43all$ git bisect good 9d57c189d74551d2b3770cc81139ea10a62e672f is the first bad commit commit 9d57c189d74551d2b3770cc81139ea10a62e672f Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon May 12 05:19:54 2014 +0000 source-hash-5b5e62650354788e50b44f32c22b687b2018aba9 commit 5b5e62650354788e50b44f32c22b687b2018aba9 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Fri Mar 28 15:22:57 2014 +0100 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Fri Mar 28 15:23:09 2014 +0100 Remove remaining DBG_CTOR etc. remnants from chart2 Change-Id: Iaf07f77b4228d4debb2620625b14ce7dc41e3a98 :100644 100644 9506902c6a27010b21fa60db2785cf8c6a99663b b7caf44d24c70027187d09beb9d1a84d3c2251d5 M ccache.log :100644 100644 f131bc060e8059666f8d7f3d448a0a6b8e1df7e4 67e626a238104bf7e45c40698e0e7cc28a4cd98c M commitmsg :100644 100644 5db1c1712e795b3ab96960366a53cf84ae3d8bca e6b0918bbb842858c3ad70bde38bc555a88e1bf0 M make.log :040000 040000 6dbe8a26ebf7cb34dc34ce783aa54092c2e9e5ed 0be05708421a37d2d8695098f2569749e3ed39de M opt The PDF files generated during bibisection and the procedure are in attachment of this message. I hope it will help. Regards, Karel Hruska
since PDF export is a key feature, I would suggest this as MAB
Added. K.H. (In reply to Cor Nouws from comment #6) > since PDF export is a key feature, I would suggest this as MAB
Got this fixed with http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aa360cae0383f270c12708e7e94179a7fde6711 ?
Created attachment 109267 [details] With 4.4.0 master exported PDF Seems that Bug 83922 (PDF export of frames, explained), Bug 84294 (PDF export of frames, bibisected, proper example), Bug 85409 (PDF export of frames, example) and probably also Bug 83963 (PDF export and transparency of text fields, explained, bibisected, example) are the same. I think that all except Bug 84294 may be marked as duplicates. Attached example "With 4.4.0 master exported PDF" is different from "With 4.2.6.3 exported PDF". Seems to me that 4.4.0 is the proper one? If that's correct, and since it cannot be reproduced with LO 4.4.0 master anymore, https://bugs.freedesktop.org/show_bug.cgi?id=84294#c8 suggests when it might've been fixed. While in 4.2 and 4.3 on right click there is Frame-Background, in 4.4 there is Frame-Transparency. Question is: can the fix be backported to 4.3?
*** Bug 83922 has been marked as a duplicate of this bug. ***
*** Bug 85409 has been marked as a duplicate of this bug. ***
This affects not only PDF but also printing. As far as I can tell, this has been fixed in the forthcoming version 4.4 (I tested this in 4.4.0.0.alpha1 on Ubuntu 14.04 64-bit).
Earlier today I filed a bug report (86578) that seems very related to this whole subject of frame backgrounds. Not only are the frame backgrounds totally opaque in the 4.4 alpha, but when I change them I can generate a pdf that shows them correctly. BUT, as I mention in 86578, if I save the Writer doc normally and then reload it, the frames I corrected earlier are back to fully opaque. So, could this issue somehow also be related to the save and/or load routines? I'll leave it to someone more knowledgable to decide whether to combine my 86578 with this one (84294) and 83693. I believe I can also testify that this is a recent regression, since I don't experience the problem in my LibreOffice 4.3 installation. Pappy Landau suggests that "As far as I can tell, this has been fixed in the forthcoming version 4.4 (I tested this in 4.4.0.0.alpha1 on Ubuntu 14.04 64-bit)." I am using the Alpha 4.4 on 64 bit Ubuntu 14.04 (see bug 86578 for details on build and so forth) and the problem as I experience it makes Writer unusable (since it obscures graphics in frames and won't let me save any fixes I make to the transparency). Interstingly, and seemingly contrary to some of the comments here, the TEXT I have in frames seems to show up fine (i.e. it's visible and shows up in the pdf export). If I can help test any fix to the 4.4 branch, I'd be happy to help if I can, as I really want the pdf fix in 4.4, and have some large documents (a book, actually) that has a variety of frames with text, graphics, and both that I can use for that purpose. Frank
Confirming as fixed with 4.4.0.0alpha1 release. Incorrect through Version: 4.4.0.0.alpha0+ Build ID: 93f9451340957dae29a6b3ccec127a99a03ffd31 TinderBox: Win-x86@39, Branch:master, Time: 2014-09-27_06:02:32 but was corrected by Version: 4.4.0.0.alpha0+ Build ID: fc24eadc6283cd03397b70fda309a578ce295f16 TinderBox: Win-x86@39, Branch:master, Time: 2014-10-03_00:31:27 So, http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aa360cae0383f270c12708e7e94179a7fde6711 for bug 80468 probably also corrected this issue.
(In reply to V Stuart Foote from comment #14) > Confirming as fixed with 4.4.0.0alpha1 release. > > Incorrect through > Version: 4.4.0.0.alpha0+ > Build ID: 93f9451340957dae29a6b3ccec127a99a03ffd31 > TinderBox: Win-x86@39, Branch:master, Time: 2014-09-27_06:02:32 > > but was corrected by > Version: 4.4.0.0.alpha0+ > Build ID: fc24eadc6283cd03397b70fda309a578ce295f16 > TinderBox: Win-x86@39, Branch:master, Time: 2014-10-03_00:31:27 > > So, > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=5aa360cae0383f270c12708e7e94179a7fde6711 for bug 80468 probably also > corrected this issue. This bug is "desperately" targeting 4.3.x, so I would not call this fixed without at least proposing a backported patch.
(In reply to Rico Tzschichholz from comment #15) > This bug is "desperately" targeting 4.3.x, so I would not call this fixed > without at least proposing a backported patch. I've asked in bug 80468 if it will be included in 4.3.
@Caolán, Reopening at OPs request. For proper handling of transparency in the PDF export filters, seems your http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aa360cae0383f270c12708e7e94179a7fde6711 (for bug 80468) resolved this filter issue on master. Which has been correct on subsequent 4.4.0 builds. Is it suitable to also port back to 4.3?
Created attachment 109901 [details] With 4.3.4.1 exported PDF I see, although just to be clear "transparency" problem, this bug is about, persists in 4.3.4rc1, which contradicts with the discussion of the bug you are referring. I added a newly generated PDF using 4.3.4rc1.
(In reply to Rico Tzschichholz from comment #18) > I see, although just to be clear "transparency" problem, this bug is about, > persists in 4.3.4rc1, which contradicts with the discussion of the bug you > are referring. I just checked in 4.3.4.1 > not good. And in 4.4.0.beta1 > good
"http://cgit.freedesktop.org/libreoffice/core/commit/?id=5aa360cae0383f270c12708e7e94179a7fde6711 (for bug 80468) resolved this filter issue on master" that isn't the same as this, that was on loading .odt files which is not the issue here which is rendering them to pdf and a different problem.
@Caolán, (In reply to Caolán McNamara from comment #20) > that isn't the same as this, that was on loading .odt files which is not the > issue here which is rendering them to pdf and a different problem. see comment 14 this issue, anything else in that range of commits that actually corrected this? And can be pushed back to 4.3?
*** Bug 83963 has been marked as a duplicate of this bug. ***
(Commented during a sweep of bugs which are bibisected but not marked as having been source bisected - although this is fixed on master, I notice that there are still pending requests for a 4.3 backport) Confirmed through bibisection/bisection that it was indeed commit 5aa360cae0383f270c12708e7e94179a7fde6711 at which master was fixed completely. sw/source/core/unocore/unoframe.cxx is rather diverged between 4.3 and master, but couldn't the corresponding hunk of that commit be relevant? @Caolán, any further thoughts? (If it's really nothing to do with the above, then I don't have any further clue on how to find the right fix. Unless anyone has any bright ideas, this may be beyond the level of effort available/reasonable in the remaining life of the 4.3 branch)
(In reply to Matthew Francis from comment #23) > this may be beyond the level of effort available/reasonable in the remaining life of the 4.3 branch) Hope not, but even if so, because there's only 4.3.7 left, that should be decided and not just left reopened.
I'd suggest we close this again, this time as WONTFIX for 4.3 As Matthew F. notes in comment 23, considerable divergence between 4.3 and 4.4--and while we've demonstrated correct commit fixing issue in 4.4--no assurance it alone would likewise correct a 4.3.7 release. And even if so, would demand a concentrated QA review, or it could introduce additional regressions we'd then not be able to correct in cycle. So, maybe best to let this go as WONTFIX.
bisect from comment #5 contains usual suspect commit 6e61ecd09679a66060f932835622821d39e92f01 4.3.0.4 has the bug, after revert of above commit so between 6e61ecd09679a66060f932835622821d39e92f01 and its revert on the libreoffice-4-3 branch something must have broken the rendering of transparent frames. ok it turns out it's caused by a early return in vcl that was removed by: commit 9153a36b59f2efc2bfb2c9256c39eb5687808deb Author: Chris Sherlock <chris.sherlock79@gmail.com> AuthorDate: Fri Mar 28 23:30:02 2014 +1100 fdo#74702 Refactor OutputDevice::DrawTransparent() fixed on master (well, pushed the fix to master anyway, it already works there due to using different paint code...) PS: the "No background" frame in the bugdoc is displayed wrong by old versions - it has fo:background-color="transparent" style:background-transparency="100%" so should be transparent. (OOo 3.3 also displays it wrong like LO 4.3)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=581314958f0ddd6c3a0536ce2d7e7e6f0c53a8ec tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 5.0.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b05c08079cc5c7bc611ce9c9c44eb5de83391cd tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 5.0.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ef6eea9c60ee82d7d56cd7dc99515ab3fbe2b17 tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 5.0.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.
ah now the bot is using the wrong branch apparently, those last 2 comments were release branches for 4.4.4 and 4.3.8
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7881067a63ee9984588dfbd0ed5013aa34d45dbb tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 5.0.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2b32cb7a06e89a86e4a961541b453df31410c126 tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 5.0.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-3-7": http://cgit.freedesktop.org/libreoffice/core/commit/?id=64e72e62eb8b6c80e9763ea0b4d4ca28dfe3a43b&h=libreoffice-4-3-7 tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 4.3.7. 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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c8dbae617b4e165c2047a7808240735f413f3360&h=libreoffice-4-4-3 tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3 It will be available in 4.4.3. 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.
This appears to be fixed in the latest master 5.0.0.0.alpha1+. Thank you.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]