Summary: | no frame background images after loading particular ODF document | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Michael Stahl <mst.fdo> |
Component: | Writer | Assignee: | Miklos Vajna <vmiklos> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | caolanm, vmiklos |
Version: | 4.3.0.0.alpha0+ Master | Keywords: | regression |
Hardware: | Other | ||
OS: | All | ||
See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=42341 https://bugs.freedesktop.org/show_bug.cgi?id=78278 |
||
Whiteboard: | odf target:4.3.0 | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 75025 |
Description
Michael Stahl
2014-05-19 12:41:18 UTC
Probably 6e61ecd09679a66060f932835622821d39e92f01 (Merge back branch alg_writerframes to trunk, 2014-03-19) is related. Bibisect range is a85145a359f5f21b2d57d822b2785a85c6566856..ffaf640b734885d2844a99cc1fd61c8a6a1d663b, contains the above mentioned commit. Aha, it seems that the bug is about how a bitmap background and transparency interacts. In the past, style:background-transparency (which is 100%, e.g. fully transparent) was ignored, and in case the user set a (semi-)transparent background e.g. to 90%, then the child style:background-image's draw:opacity attribute was set to 100-value, so "10%" in this case. The new behavior is incompatible (though it's consistent with drawinglayer shapes): it parses style:background-transparency, that's how in the document the background bitmap is not visible. Michael: I guess the fix would be to make sure that we ignore style:background-transparency if draw:opacity is present. I tried to do that, but it seems that the normal content filters are evaluated only for the style:graphic-properties's attributes, not for child elements' attributes (like style:background-image); I wonder if you know of an example where we handle something like this already. WIP patch: http://pastebin.com/raw.php?i=gzRM8sgr http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b66810f17c1000ac1d4dc3c5ba49842a0d146be and the commits right before it fix this bug. -4-3 review: https://gerrit.libreoffice.org/10025 -4-3 review, second try: https://gerrit.libreoffice.org/10077 Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc17dad5fd7509f191718df8690e5847ab87669a&h=libreoffice-4-3 fdo#78908 Revert "Merge back branch alg_writerframes to trunk" It will be available in LibreOffice 4.3.1. 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. Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-4-3-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=18c105107b5664c3247274dbb629781606029634&h=libreoffice-4-3-0 fdo#78908 Revert "Merge back branch alg_writerframes to trunk" It will be available already in LibreOffice 4.3.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. |
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.