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.
@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.
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
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 ***
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.
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.
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
(In reply to V Stuart Foote from comment #4) > ... splitting it back out from bug 84294. s/84294/80294/
(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.
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.
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.
*** Bug 88337 has been marked as a duplicate of this bug. ***
*** Bug 89478 has been marked as a duplicate of this bug. ***
*** Bug 85283 has been marked as a duplicate of this bug. ***
Whiteboard -> bibisectRequest
*** Bug 87369 has been marked as a duplicate of this bug. ***
see https://bugs.documentfoundation.org/show_bug.cgi?id=87369#c9
*** Bug 89730 has been marked as a duplicate of this bug. ***
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.
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.)
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
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.
*** Bug 90055 has been marked as a duplicate of this bug. ***
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).
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.
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...
(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
@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
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
@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.
(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/
Stuart, no worries, all of these dupe bugs are pretty bad so i'll try to look through them asap anyway.
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.
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
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
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
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.
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.
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]