Bug 94287 - FORMATTING: None-filled frame anchored to transparent frame stacks transparency
Summary: FORMATTING: None-filled frame anchored to transparent frame stacks transparency
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Frame-Dialog Regressions-alg_writerframes
  Show dependency treegraph
 
Reported: 2015-09-16 21:09 UTC by tmacalp
Modified: 2021-03-02 03:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
frames (27.06 KB, image/png)
2015-12-20 08:34 UTC, raal
Details
Test document with example screenshots (76.22 KB, application/vnd.oasis.opendocument.text)
2015-12-21 16:47 UTC, tmacalp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2015-09-16 21:09:06 UTC
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.
Comment 1 Buovjaga 2015-09-20 15:38:21 UTC
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)
Comment 2 raal 2015-12-20 08:34:12 UTC
Created attachment 121420 [details]
frames

Please could you attach test file? I can not reproduce, thanks
Comment 3 tmacalp 2015-12-21 16:47:04 UTC
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
Comment 4 raal 2015-12-21 21:35:42 UTC
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
Comment 5 raal 2015-12-21 21:36:12 UTC
(In reply to tmacalp from comment #3)
> Created attachment 121476 [details]
> Test document with example screenshots
> 
Thanks for test document!
Comment 6 Armin Le Grand 2016-01-07 10:54:20 UTC
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.
Comment 7 Armin Le Grand 2016-01-07 11:11:05 UTC
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'.
Comment 8 tmacalp 2016-01-07 15:44:29 UTC
(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.
Comment 9 QA Administrators 2017-10-23 14:13:48 UTC Comment hidden (obsolete)
Comment 10 tmacalp 2017-11-03 13:23:37 UTC
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
Comment 11 QA Administrators 2019-03-02 03:50:40 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2021-03-02 03:48:44 UTC
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