Transparency was reworked a bit in LibreOffice 4.4.x. Before that version, frames with a fill type of "None" that were anchored to other frames with a background with transparency would MATCH the same level of transparency in areas where the two frames overlapped. This would make the child frame appear to really not have a background and emulate being 100% transparent in areas where the two frames overlapped. Starting in LO 4.4.x, frames no longer perform this magic and the child simply STACKS the transparent background on top of the parent frame. Frames with a background of "none" are a tricky beast. Not only are they unintuitive, but they're also the default fill! None-filled frames simply inherit the background color of their anchor point. Bug 34585 is about fixing/working around this behavior. Steps to reproduce: 1. New writer document 2. Insert a frame with a fill of solid, 50% transparent 3. Click in that frame and insert another frame with a fill of "none" Expected: Our inner frame's fill should effectively look as if it were 100% transparent and not be any darker than the parent frame. Actual: Our inner frame inherits the 50% black frame of the parent, and that 50% black fill stacked with the parent's 50% black results in a section that looks closer to black with only 25% transparency. Related Notes: While the previous matching behavior was better than the current stacking behavior, why are we even still dealing with confusing "None" filled frames inheriting the backgrounds of parent frames? Why aren't "None" filled frames equivalent to 100% transparent frames? They might be less efficient to render or we could have backwards compatibility issues, I guess. But I think they need to be dropped at some point. OpenOffice still has an open bug from 2003 (OpenOffice 1.1), when they realized none-filled vs 100% transparent frames would lead to a confusing mess. https://bz.apache.org/ooo/show_bug.cgi?id=20209 This bug affects LibreOffice 4.4.4.3, but not LibreOffice 4.3.4.1.
Reproduced. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ (x64) Build ID: 9ce08dcc2e32c5554ddf71b79173f8854e0568ad TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-09-17_21:43:51 Locale: en-US (fi_FI)
Created attachment 121420 [details] frames Please could you attach test file? I can not reproduce, thanks
Created attachment 121476 [details] Test document with example screenshots Here is a test document. If you're not able to reproduce it under Windows, it might end up being a Linux only bug? I've also found that I get the previous transparency behavior when opening documents created with previous LO versions. For example, here is an example document I created for another bug report. https://bugs.documentfoundation.org/attachment.cgi?id=95338
This seems to have begun at the below commit. Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one? Thanks af1025800ec5bd1184da14f92a494470fa7c490b is the first bad commit commit af1025800ec5bd1184da14f92a494470fa7c490b Author: Matthew Francis <mjay.francis@gmail.com> Date: Thu May 28 20:34:05 2015 +0800 source-hash-6e61ecd09679a66060f932835622821d39e92f01 commit 6e61ecd09679a66060f932835622821d39e92f01 Author: Armin Le Grand <alg@apache.org> AuthorDate: Wed Mar 19 16:17:02 2014 +0000 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Fri Mar 28 14:31:08 2014 +0100 Merge back branch alg_writerframes to trunk (cherry picked from commit b635b4fa4e42053d30ab639643d2236a20243f62) Conflicts: comphelper/inc/comphelper/TypeGeneration.hxx comphelper/source/property/TypeGeneration.cxx cui/source/factory/dlgfact.hxx cui/source/inc/cuitabarea.hxx cui/source/tabpages/tabarea.cxx cui/source/tabpages/tabarea.hrc cui/source/tabpages/tabarea.src cui/source/tabpages/tparea.cxx drawinglayer/source/primitive2d/polypolygonprimitive2d.cxx drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx drawinglayer/source/texture/texture.cxx editeng/inc/editeng/unotext.hxx editeng/source/items/frmitems.cxx include/drawinglayer/texture/texture.hxx include/editeng/brushitem.hxx include/svx/sdr/primitive2d/sdrdecompositiontools.hxx include/svx/svxids.hrc include/xmloff/xmltypes.hxx reportdesign/source/ui/misc/UITools.cxx sc/source/ui/drawfunc/drawsh.cxx sfx2/source/dialog/tabdlg.cxx svl/source/undo/undo.cxx svx/inc/svx/unoshprp.hxx sw/Library_sw.mk sw/inc/doc.hxx sw/inc/format.hxx sw/inc/frmfmt.hxx sw/inc/swatrset.hxx sw/inc/unomap.hxx sw/inc/unoprnms.hxx sw/source/core/access/accpara.cxx sw/source/core/attr/format.cxx sw/source/core/attr/swatrset.cxx sw/source/core/doc/docdraw.cxx sw/source/core/doc/docfly.cxx sw/source/core/doc/notxtfrm.cxx sw/source/core/inc/frame.hxx sw/source/core/inc/frmtool.hxx sw/source/core/layout/atrfrm.cxx sw/source/core/layout/paintfrm.cxx sw/source/core/text/inftxt.cxx sw/source/core/text/porfld.cxx sw/source/core/text/txtfly.cxx sw/source/core/txtnode/fntcache.cxx sw/source/core/uibase/app/docst.cxx sw/source/core/uibase/app/docstyle.cxx sw/source/core/uibase/shells/drawdlg.cxx sw/source/core/uibase/shells/frmsh.cxx sw/source/core/unocore/unoframe.cxx sw/source/core/unocore/unomap.cxx sw/source/core/unocore/unoprnms.cxx sw/source/core/unocore/unostyle.cxx sw/source/ui/fmtui/tmpdlg.cxx sw/source/ui/fmtui/tmpdlg.src sw/source/ui/frmdlg/frmdlg.cxx sw/source/ui/frmdlg/frmpage.src sw/source/ui/inc/frmsh.hxx xmloff/source/text/txtprhdl.cxx xmloff/source/text/txtprmap.cxx Change-Id: Id3ffaa83bb5594d287f1ac8f2c1c9cf55c70946d
(In reply to tmacalp from comment #3) > Created attachment 121476 [details] > Test document with example screenshots > Thanks for test document!
Probably has to do with that commit - this was the deep change to allow for any standard-FillStyle combination for Writer Frames/Pages/... This was not only for transparency, but for none/color/gradient/hatch/graphic fill and shadow. Someone has to decide if this is an error or not, as already claimed in the related notes. I remember that I was astonished myself about 'None' leading to inherit from parent when implementing. As it seems I missed at that time that 'inherit' is only for non-overlapping parts of child and parent. Or the other way round: Do not inherit in overlappinmg parts (equivalent with not painting child in overlapping parts?). All this is confusing and from my POV not what a user expects. When the user sets a child frame to fill==none, it just should not be filled. Everything else is unintuitive for me. Instead of adding work for this case (frames in frames, hopefully not used often) I pled for using 'None' as none, same as transparency==100%, no fill. No inherit from parent frame. As tmacalp mentions, this will break compatibility.
I have an idea how this happened, though. First, Writer had no transparence (old versions), so using parent's FillStyle for Frames in Frames looks the *same* as 'None', except when it got allowed to move frames outside their parens (probably later). The 'None' FillStyle child was painted filled eventually just to make text behind it 'covered/disappearing'. Next, transparence was implemented, so a solution had to be found to make 'None' look the same - lot of 'special' code was added to *not* draw transparent layered frames which would look different from 'None'. BTW: Checked a old version, this 'special code' does not work in all cases. Try a text frame, make 50% transparent, add two child frames -> overlappings with parent are not pained layered, overlapping of childs *are* painted layered - sigh :-( Also checked Word - Frames in Frames are not possible -> cannot be done there at all. One more reason to clean this up - I opt for using 'None' as 'None'.
(In reply to Armin Le Grand from comment #6) > Instead of adding work for this case (frames in frames, hopefully not used > often) I pled for using 'None' as none, same as transparency==100%, no fill. > No inherit from parent frame. As tmacalp mentions, this will break > compatibility. I actually use frames within frames quite often. For instance, you would need a frame within a frame any time you have a captioned picture in a frame. Frames are vital for handling complex page layouts. I agree with you that the current none-filled frame behavior is confusing and needs to die. It's obviously not a decision to be taken lightly, but we will need to bite the bullet at some point. A decade ago this behavior was already referenced as a "historical design flaw." As mentioned in my original post, the primary report for that behavior is bug 34585. Since it's somewhat related, I'll add it as a see-also.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Can still repro in Version: 5.4.2.2 Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group
Dear tmacalp, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.
Dear tmacalp, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug