Bug Hunting Session
Bug 86578 - Text frame and coincident image frame style transparency and color fill corruption in Writer 4.4
Summary: Text frame and coincident image frame style transparency and color fill corru...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha2
Hardware: x86-64 (AMD64) All
: highest blocker
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:5.0.0 target:4.4.3
Keywords: bibisected, bisected, regression
: 90055 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2014-11-22 13:42 UTC by Frank
Modified: 2015-12-17 08:39 UTC (History)
18 users (show)

See Also:
Crash report or crash signature:


Attachments
odt Document to illustrate bug 86578 (143.82 KB, application/vnd.oasis.opendocument.text)
2014-11-23 00:53 UTC, Frank
Details
document with both writer image and drawing object (31.34 KB, application/vnd.oasis.opendocument.text)
2015-04-10 21:51 UTC, Michael Stahl (CIB)
Details
4.4.3+ a.pdf compared to ODT opened in 4.5.0alpha0+ (294.10 KB, image/jpeg)
2015-04-14 15:09 UTC, V Stuart Foote
Details
repackaged testcase by Paddy L. (498.86 KB, application/zip)
2015-04-14 15:14 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank 2014-11-22 13:42:18 UTC
I'm using 64 bit Ubuntu 14.04 with a parallel installation (with separate user profile, etc.) of LibreOffice Version: 4.4.0.0.alpha2+
Build ID: d273a60bfdbf9bb7623bed38667ec0647753157c - TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-11-20_03:05:21 - Locale: en_US

I know this is similar to Bug 75093, but it is quite real and reproducible on my machine, and does not occur with my day-to-day 4.3 installation.

While attempting to test the improved pdf export in 4.4 (BIG Improvement in pdf file sizes by the way), I thought that perhaps the smaller size resulted from the fact that Writer just left out quite a few of my graphics, which didn't appear in the resulting pdf.

A little further exploration, however, showed that they were not visible in the document either, although seemed to in fact still be there - just hidden under totally (and newly) opaque non-transparent frames. Thinking that maybe this was a result of some sloppy formatting on my part, I changed a few of the frames to 100% transparency - permitting the graphic, which was already marked as "on top" to be displayed in Writer and then saved the file (yes - under a new name).

I generated a new pdf and - viola - the graphics whose frames I had "fixed" showed up in the pdf.

HOWEVER, when reloading the document, all of the frames were again totally opaque. To cut this short, I checked and changed the style for frame contents to 100% transparency as well, but that did made no difference in the results. The bottom line is that I can't use Writer 4.4 if there are graphics in frames.

Graphics that I had placed in borderless tables, by the way, show up fine and export to pdf properly, etc.

All Frames that I checked in the document (several hundred pages, so I didn't hit every one) show up in the dialog box as 50% transparency, although graphics placed in the frame (although not text, which was still visible) were completely invisible - suggesting that the transparency is really 0%.

So ... The fact that Writer doesn't save the transparency of the frame would seem to be a bug. I suspect the change of the earlier default of 100% transparency (actually I don't recall ever setting frame transparencies before) may be unintentional as well if this is a new enhancement.

QA folks or developers are welcome to contact me via e-mail if there are any other questions I can answer or things they would like me to try - I really want the improved pdf export, but can't use 4.4 as is (yes - I know it's an alpha, but I'm old and impatient :)

Frank

ADDITIONAL COMMENT:

While writing this, I happened to notice that the graphics that disappeared possibly had something in common: each of them was set to "in background" in a frame that was formatted with two columns. I'm not sure if this is a "clue" or not but thought I should mention it.
Comment 1 V Stuart Foote 2014-11-22 20:03:47 UTC
@Frank,

Not clear, are your working in ODF .odt or in filtered .doc format?

How a bout a sample test document and your concise steps to reproduce.

This is likely related to handling of background fill--bug 81223 and the export bug 84294 and friends--but is not the same issue.
Comment 2 Frank 2014-11-23 00:53:59 UTC
Created attachment 109872 [details]
odt Document to illustrate bug 86578

Here you are - with my best wishes and encouragement.

You can fix this - even the Bears won a game last weekend, so anything is possible!!

Let me know if you need anything else.

Frank
Comment 3 V Stuart Foote 2014-11-23 21:06:10 UTC
Pretty sure this will end up being a duplicate of fdo#80294, see https://bugs.freedesktop.org/show_bug.cgi?id=80294#c2 and c9.

@Miklos, does this make sense?

*** This bug has been marked as a duplicate of bug 80294 ***
Comment 4 V Stuart Foote 2014-11-26 05:57:48 UTC
Going to reopen and set back to NEW

This issue starts with 4.4.0 builds, which retain Armin Le Grand's writer frames refactoring http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e61ecd09679a66060f932835622821d39e92f01--which was reverted for the 4.3 builds.   So, splitting it back out from bug 84294.

For 4.4.0 branch forward, there seems to be issues with the Writer style:graphic-properties in the content.xml and the styles.xml 

It seems like the XML of a coincident image frame and text frame are conflicting, and when the document is being saved back to its ODF archive something is being dropped in writing the XML. On reopen transparency and area fill have changed. 
 
The image frame is loosing color for area fill (resetting to white), and also some of the transparency elements. It will hold other area fill types.

It also seems that with introduction of transparency for image frame--the Image dialog Wrap -> Through -> In bac~kground is being set--but the frame for the image is conflicting with the coincident text frame drawing layer. 

If the text frame is assigned an area fill (Color, Gradient, Hatching, or Bitmap) and a transparency value--then the image frame will correctly render. But if an text frame area fill NONE is set, the coincident image frame will not render the image and its frame will show opaque. 

Unfortunately setting transparency of the text frame is cleared to no transparency when the document is saved and reopened. So the image shows opaque. The issue of sample document provided by OP.

Also, the text frame with a Color area fill will reset to color White.
Comment 5 V Stuart Foote 2014-11-26 06:02:16 UTC
Resetting NEW and adding to mab4.4

The Writer Frames refactoring is a nice bit of work, but looks to still need some tweaks. There is loss of formatting style of coincident image frames and text frames occurring between an .ODT document save and reopen.
Comment 6 V Stuart Foote 2014-11-26 06:12:43 UTC
ref the attachments posted to 80294 applicable to this issue

zip with PNGs -- converted with Alpha chnl transparency
https://bugs.freedesktop.org/attachment.cgi?id=109914

zip of sample .odt and PDFs of 4.3.4.1 and 4.4.0beta1 renderings
https://bugs.freedesktop.org/attachment.cgi?id=109915
Comment 7 V Stuart Foote 2014-11-26 06:39:54 UTC
(In reply to V Stuart Foote from comment #4)
> ... splitting it back out from bug 84294.

s/84294/80294/
Comment 8 Björn Michaelsen 2014-12-18 10:22:03 UTC
(This is an automated message.)

Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Comment 9 Regina Henschel 2015-01-11 19:26:38 UTC
The attribute draw:opacity="0%" is removed on saving, when the draw:fill="none" attribute is present. So you cannot workaround the problem by explicitly setting transparent=100% in the UI.

This error is similar to issue 88295 and might be connected with the wrong handling of draw:fill="none" in old OpenOffice, see https://issues.apache.org/ooo/show_bug.cgi?id=20209.
Comment 10 Claude 2015-01-16 14:58:04 UTC
I´ve found that the color filling of a frame does not stick on saving the document.  Might be related.  (The background color of a text box remains though)
Versión 4.4.0.2.  Windows 8.
Worked fine until 4.3.5

To produce de bug:  Create New document.  Create a text frame.  Set color fill.
Save document.  Reopen document.  Frame appears with no color background.
Comment 11 V Stuart Foote 2015-03-04 16:33:43 UTC
*** Bug 88337 has been marked as a duplicate of this bug. ***
Comment 12 V Stuart Foote 2015-03-04 16:34:08 UTC
*** Bug 89478 has been marked as a duplicate of this bug. ***
Comment 13 V Stuart Foote 2015-03-04 16:34:15 UTC
*** Bug 85283 has been marked as a duplicate of this bug. ***
Comment 14 Robinson Tryon (qubit) 2015-03-05 16:24:56 UTC
Whiteboard -> bibisectRequest
Comment 15 V Stuart Foote 2015-03-15 23:25:17 UTC
*** Bug 87369 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2015-03-15 23:38:42 UTC
*** Bug 89730 has been marked as a duplicate of this bug. ***
Comment 18 V Stuart Foote 2015-03-15 23:55:14 UTC
bumping to critical, not a blocker--but this residual mishandling and loss of colors and transparency for frames is quite an annoyance--

All started with refactoring with Armin L's: 

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6e61ecd09679a66060f932835622821d39e92f01

and subsequent

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7d9bb549d498d6beed2c4050c402d09643febdfa

they were backed out of 4.3, but have had ongoing issues on master now as 4.4

Recall seeing bits and drabs of patches against 4.3, and 4.4 but has never really been resolved.
Comment 19 Paddy Landau 2015-03-16 12:37:07 UTC
According to the following flowchart…

https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

… this should be Importance: Highest + Blocker, especially as this mis-saving happens silently; it causes loss of data without warning.

(As explained in bug #87369, this would mean — literally! — thousands of problems per year for just one of my files. It is preventing me from upgrading from 4.3.)
Comment 20 Rico Tzschichholz 2015-03-16 18:11:55 UTC
Same here, and I am even stuck with 4.2.8 for specific documents, because 4.3.x is still broken by this related problem https://bugs.documentfoundation.org/show_bug.cgi?id=84294
Comment 21 Regina Henschel 2015-03-16 20:45:21 UTC
LibreOffice is confused by the draw:fill-color attribute of the frame style. If you remove it, the background color is read correctly. You can easily test this, when you save to .fodt and remove the attribute manually.
Comment 22 Matthew Francis 2015-03-25 13:22:39 UTC
*** Bug 90055 has been marked as a duplicate of this bug. ***
Comment 23 Michael Stahl (CIB) 2015-04-10 21:41:41 UTC
the ALG commit disabled some horrible special-case hack to
paint flys anchored at other flys specially defying the
defined z-order; this is quite awful and good to see it gone
but probably we should restore it for the legacy documents.

also most of the bugs resolved as duplicate of this one
are apparently 3 or so different bugs (that were all
introduced by the same commit).
Comment 24 Commit Notification 2015-04-10 21:41:57 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5cf8824a619401627f18abc7b3049551c71ac2a

tdf#86578: sw: fix rendering of legacy documents with fly achored at fly

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.
Comment 25 Michael Stahl (CIB) 2015-04-10 21:51:33 UTC
Created attachment 114732 [details]
document with both writer image and drawing object

if you're curious how crazy this "feature" actually is, look at this attachment...
Comment 26 Matthew Francis 2015-04-11 00:51:43 UTC
(In reply to Michael Stahl from comment #23)
> also most of the bugs resolved as duplicate of this one
> are apparently 3 or so different bugs (that were all
> introduced by the same commit).

Noted, will try to be careful of that in future for more than trivially sized commits
Comment 27 V Stuart Foote 2015-04-11 01:13:16 UTC
@Michael S., when a TB daily rolls with the patch will of course test against each of the duplicate cases.  Do you prefer they be reopened if not resolved by your rework?  Or post as new specific bugs? Or just tack them on here?

Stuart
Comment 28 Frank 2015-04-11 12:49:19 UTC
As the submitter of the bug, I'm eager to test these fixes, but how do I know where to find them?

Michael says it will be available in 5.0 which is either week 16 (freeze) or week 21 (release), and also that it will be in the daily builds in 24 or 48 hours.

Sorry I'm not familiar with how this all works, but should I get the fixed version from the 4.x line or the 5.x line, or will it be in both?

And thanks much for attacking this extremely annoying (at least to me) problem. I look forward to seeing how it works.

Frank
Comment 29 V Stuart Foote 2015-04-11 15:09:28 UTC
@Frank, *
(In reply to Frank from comment #28)
> As the submitter of the bug, I'm eager to test these fixes, but how do I
> know where to find them?

No worries, unless you build from git pulls yourself, or work regularly with the TinderBox builds it can be a bit confusing.

Description of the LibreOffice Tinderbox infrastructure
https://wiki.documentfoundation.org/Development/Tinderbox

Current status monitoring of the Tinberboxes
http://tinderbox.libreoffice.org/index.html

Owners of the various TinderBox systems may or may not post to the "Daily" build repository hosted by the project. But you should be able to find current builds of master or 4.4 or soon 4.5 here:  http://dev-builds.libreoffice.org/daily/

So, Michael S's patches have been applied to the master branch. Those that will become the 5.0 release.  And, at this point, the corrections have not been "backported" to the 4.4 release builds. Doing that will depend on the reviews that folks give of the effectiveness in a current build of master--and a decision made to backport if warranted and of low risk.

Let us know how you make out.
Comment 30 V Stuart Foote 2015-04-11 15:11:49 UTC
(In reply to V Stuart Foote from comment #29)
Sorry correct that a bit...

s/builds of master or 4.4 or soon 4.5 here/builds of master, or 4.4, or soon 5.0 here/
Comment 31 Michael Stahl (CIB) 2015-04-11 15:19:50 UTC
Stuart, no worries, all of these dupe bugs are pretty bad so i'll try to look through them asap anyway.
Comment 32 Commit Notification 2015-04-11 20:24:15 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=312fc74f5bb49da4066ace46558179a03e164556&h=libreoffice-4-4

tdf#86578: sw: fix rendering of legacy documents with fly achored at fly

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.
Comment 33 Paddy Landau 2015-04-14 13:25:53 UTC
Alas, this patch has not fixed the problem. I have installed the latest Linux version, which became available earlier today, from here:

http://dev-builds.libreoffice.org/daily/libreoffice-4-4/Linux-rpm_deb-x86_64@46-TDF/2015-04-13_23.32.10/

The problems remain.

I shall attach some samples files for testing in file "Bug #87369.zip" as follows.

• Bug #87369 4.3.6.2.odt    : Created in 4.3.6.2

 → Bug #87369 4.3.6.2 a.pdf : As shown when saved but before closing
 → Bug #87369 4.3.6.2 b.pdf : As shown after reopening in 4.3.6.2
 → Bug #87369 4.3.6.2 c.pdf : As shown when opened by 4.4.3.0.0+ (Dev)
 → Bug #87369 4.3.6.2 c.pdf : As shown when saved then reopened by 4.4.3.0.0+ (Dev)

• Bug #87369 4.4.3.0+.odt   : Created in 4.4.3.0.0+ (Dev)

 → Bug #87369 4.4.3.0+ a.pdf: As shown when saved but before closing
 → Bug #87369 4.4.3.0+ b.pdf: As shown when reopened

I am marking this bug as Reopened.

More information: Linux Ubuntu 14.04 64-bit
Comment 34 Paddy Landau 2015-04-14 13:30:35 UTC
I cannot attach the file. Therefore, here is a link to the folder on Dropbox.

https://dl.dropboxusercontent.com/u/49313422/LibreOffice%20bug%20%2387369/Bug%20%2387369.zip
Comment 35 V Stuart Foote 2015-04-14 15:09:03 UTC
Created attachment 114787 [details]
4.4.3+ a.pdf compared to ODT opened in 4.5.0alpha0+

@Paddy,

A good test case, will rebundle and post to this issue rather than dropbox.

However, as shown, the 4.4.3+ ODT does open correctly in 4.5.0alpha0+
Version: 4.5.0.0.alpha0+ (x64)
Build ID: 79f64d75b25ebb7fdf9f827218cd8a762dc2739b
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-14_05:46:17
Locale: en_US

So, there is another element affecting the 4.4 builds that may need backport.

The 4.3.6 ODT does have the issues described in the Explain.txt
Comment 36 V Stuart Foote 2015-04-14 15:14:38 UTC
Created attachment 114788 [details]
repackaged testcase by Paddy L.

File names Paddy L. used caused issues with upload. Renamed and zip'd and posting test case here on TDF BZ.
Comment 37 Michael Stahl (CIB) 2015-04-14 16:17:27 UTC
now i've sorted out the wrong duplicates and fixed 2 ODF related bugs,
while Caolan has fixed another 1-2 about frame backgrounds.

the attachment from comment #36 looks like a different bug too,
please check if it's still buggy on tomorrow's master builds
and if so file a *new* bug.
Comment 38 Paddy Landau 2015-04-15 19:28:13 UTC
The background colour has been fixed, but a new bug has been introduced. It removes the background graphic and will not allow it to be re-added!

I have reported this as bug #90640.
Comment 39 Robinson Tryon (qubit) 2015-12-17 08:39:46 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]