Bug 86578

Summary:	Text frame and coincident image frame style transparency and color fill corruption in Writer 4.4
Product:	LibreOffice	Reporter:	Frank <foberle>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---	QA Contact:
Severity:	major
Priority:	highest	CC:	cno, foberle, mst.fdo, rb.henschel, vmiklos, vstuart.foote
Version:	4.4.0.0.alpha2	Keywords:	regression
Hardware:	x86-64 (AMD64)
OS:	All
See Also:	https://bugs.freedesktop.org/show_bug.cgi?id=80294 https://bugs.freedesktop.org/show_bug.cgi?id=88295
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:
Bug Blocks:	79641
Attachments:	odt Document to illustrate bug 86578

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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.