I have been using OpenOffice on Mac OS X to print address labels with a jpeg background but would like to use LibreOffice instead due to issues with OO.
While the old document opens OK in LO, the background of the text layer does not appear to be transparent and thus the background image is not visible.
I just installed LO 6.2.2 for windows (win 10) and now I can at least see the background image and field names in the document, but when I print to a pdf the image is gone.
I've also upgraded to pre-release 220.127.116.11, but it behaves the same.
Steps to Reproduce:
1. Download and unpack http://hax.se/testkort.zip
2. Open the Testkort.odt document in Writer
3. Register the Testadresser.odb database (testadresser.ods is the source)
4. Print the document to a pdf file
5. Open the resulting pdf file
Address labels with only the names, no background image
Address labels with both background image and names similar to the result from the OpenOffice result provided in the file test2.pdf
User Profile Reset: No
I suspect the issue is that the top text layer is not transparent
Version: 18.104.22.168 (x64)
Build ID: 9ba025bafb03b962c34687cf87806cc03a3a7436
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win;
Locale: sv-SE (en_SE); UI-Language: en-US
Users on the Swedish LO mailing have verified my results.
I have been trying different versions and versions from 22.214.171.124 up to 126.96.36.199 works ok, but as of 188.8.131.52 it no longer works.
A colleague found this article that might be relevant: https://superuser.com/questions/971892/how-do-i-set-a-background-image-in-libreoffice-writer-5
Thomas, I just opened testkort.odt, but I couldn't reproduce it with
Version: 184.108.40.206 (x64)
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win;
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Perhaps a user of Swedish LO mailing list can confirm it here, since they could verified your results.
Build ID: 4abdaf4afb2245d404f6709124b3c627b07b8a3c
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
This report is more complicated than needed and not clear. It's wrong to attach zip, should be single files. While reporter is using mail merge, that may not be a bug, so it needed to be clear and if not so, single ODT was supposed to be attached. There's no "wrong" PDF, just "right", not clear what's missing. Reporter marked 4.4 as starting version, is it really so, tested or just like that. Regression was marked but not explained.
That being said, I used just ODT without serial print and I see images in Windows 7 so not clear what's the bug. Export to PDF also seems to work.
I revert to NeedInfo.
We have separate bug here in master, images are flipped, but let's first clarify the starting position.
I reproduces missing images in Linux with 4.4 but it was fixed in 6.0 series.
So it's not clear for report and confirmation.
Thomas and Xisco, please respond.
I just installed 220.127.116.11 on Windows 10, and it seems to work.
I will try out with real data on OSx when I get home.
Looking good so far, thanks!
Just tested 18.104.22.168, and it seems that the background graphics works now.
Now I just need to figure out how to produce the labels, just opening the document that works in OO does not work...
af1025800ec5bd1184da14f92a494470fa7c490b is the first *bad* commit
Author: Matthew Francis <firstname.lastname@example.org>
Date: Thu May 28 20:34:05 2015 +0800
Author: Armin Le Grand <email@example.com>
AuthorDate: Wed Mar 19 16:17:02 2014 +0000
Commit: Miklos Vajna <firstname.lastname@example.org>
CommitDate: Fri Mar 28 14:31:08 2014 +0100
Merge back branch alg_writerframes to trunk
(cherry picked from commit b635b4fa4e42053d30ab639643d2236a20243f62)
b1008b030246939187e5c30ba750d6abb397161d is the first *good* commit
Author: Jenkins Build User <email@example.com>
Date: Thu Jun 22 02:10:02 2017 +0200
Same range that fixed this made problem in bug 128871. Can't says which source.
Turned out the problem was not fixed after all.
The thing that did change was that the background image is visible on screen, but when printing to pdf, and I assume it will be the same when printing to a printer, the background image is not visible, just the text.
Just tested on linux, and it behaves the same.
The document looks ok in Writer, with the field names on the labels shown, but when I try to print, the preview shows just the text, no background image, and when I print to a PDF it contains just the text as well.
Please go back to basics per Comment 3 and explain:
- do you reproduce the problem you see just with ODT (no ODS and ODB needed, serial letter: no)?
- attach PDFs you get.
- try to change openGL and HW acceleration in Options-View
- write exact Win and Lin versions you tested with.
Created attachment 160975 [details]
ODT label document with background images
This is the master ODT document, with background images, to be used to generate labels.
Created attachment 160976 [details]
ODS document with names for the labels
Created attachment 160977 [details]
PDF printout from linux
Created attachment 160978 [details]
PDF printout from win10
- As far as I know you need both the ODT and an address source for this to work.
I have attached both the ODT and a short ODS document, which the ODT document refers to
- I have attached PDF:s both from linux (ubuntu 18.04.4 LTS) and windows 10 (Windows 10 Enterprise version 1909)
When I opened one of the PDF:s the background images briefly flashed by once, so I suspect the background is there, but that the text layer is on top of it and has a non transparent background so that it hides the background image.
Created attachment 160979 [details]
PDF export from Win7 LO70+
(In reply to Thomas Törnblom from comment #16)
> - As far as I know you need both the ODT and an address source for this to
No, you can simply print ODT. Please do it, to be the same.
Because my PDF export is fine.
Created attachment 160980 [details]
PDF print from Win7 LO70+
PDF print from 7.0+ has another bug, image is flipped.
(In reply to Timur from comment #11)
> - try to change openGL and HW acceleration in Tools-Options-View
> - write exact Libreoffice versions in Win and Lin you tested with.
It works if you just print the ODT document, but doesn't if you generate a document with the names from the ODS file.
The LO version (win10) is:
Version: 22.214.171.124 (x86)
Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8
CPU-trådar:4; Operativsystem:Windows 10.0 Build 18363; UI-rendering: GL; VCL: win;
Språkinställning: sv-SE (sv_SE); UI-språk: sv-SE
The linux version:
Build ID: 1:6.0.7-0ubuntu0.18.04.10
CPU threads: 1; OS: Linux 5.3; UI render: default; VCL: gtk3;
Locale: sv-SE (en_US.UTF-8); Calc: group
I have no "OpenGL" settings, but enabling OpenCL made no difference.
OK, I confirm the bug with mailmerge serial print in 6.4 but that is fine with master 7.0+. So I change back to Fixed
What I bibisected previously was simple print.
Flipped image will be another bug.
For the future: when reporting mailmerge bug, please use new sample from built-in Bibliography database.
1. Fixed is for bibisect I did in 6.0
2. Another bibisect in 7.' could reveal this fix
3. Thomas, you may report new 7.0+ flipped image (you may install master separately to your working LO).
I assume this will be fixed once 7 advances so that one can add an Address Book Source, which seems impossible with 126.96.36.199.alpha1 on OSx.
(In reply to Timur from comment #22)
> 1. Fixed is for bibisect I did in 6.0
> 2. Another bibisect in 7.' could reveal this fix
> 3. Thomas, you may report new 7.0+ flipped image (you may install master
> separately to your working LO).
Do you know which commit fixed this issue ?
Mail merge fixed in 7.0 with:
9224ac67849062bc3046578d354c642e3d9ff9c5 is the first good commit
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Thu Apr 23 09:45:17 2020
Previous source 7a714957f28758f9b112abc1bda8f502052c7b01
commit 539a5501e6732b5083e112e76511024c8ce9678a [log]
author Miklos Vajna <email@example.com> Wed Apr 22 21:06:58 2020 +0200
committer Miklos Vajna <firstname.lastname@example.org> Thu Apr 23 09:20:40 2020 +0200
parent 7a714957f28758f9b112abc1bda8f502052c7b01 [diff]
sw: handle SubtractFlys when replacing compat options
This was added in commit c5cf8824a619401627f18abc7b3049551c71ac2a
(tdf#86578: sw: fix rendering of legacy documents with fly achored at
fly), it's off by default and on for legacy ODT files.
I do confirm https://git.libreoffice.org/core/+/539a5501e6732b5083e112e76511024c8ce9678a%5E!/ fixes this issue. Le'ts backport it to libreoffice-6-4. Thanks for bisecting it!!
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":
tdf#124790: sw: handle SubtractFlys when replacing compat options
It will be available in 6.4.5.
The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.