Created attachment 128864 [details]
1. Open the attached file
2. Export it to PDF
Observed behaviour: Some of the arrows in the second page are lost
Build ID: 757a60d01dd152aadab2ba3c8224252481ce8a88
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout
Locale: ca-ES (ca_ES.UTF-8); Calc: group
but not in
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Actually I've just realized all the text after the shape is lost too
Created attachment 128865 [details]
The embedded image on second page is a WMF, attached.
If extracted and opened in Draw, export to PDF of just the WMF has same loss of graphical & text elements.
Created attachment 128872 [details]
WMF image from pg2 of MS Word .doc file losing detail on export to PDF
For additional examples...
Extracting the EMFs from http://www.cgedd.fr/prix-immobilier-friggit.doc (bug 80508 bug 80389) and attachment 101574 [details] (bug 80389) export to PDF shows the same loss of content from the EMF/WMF in the PDF export filter.
Strange, it looks fine with the below daily build in Windows 7. Somehow I doubt this got magically fixed between 11-14 and 11-17...
Stuart, which version did you use for testing?
Build ID: c03c77ef4f46b81cd000ea26c4ef154044322535
CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; Layout Engine: new;
TinderBox: Win-x86@39, Branch:master, Time: 2016-11-17_00:29:08
Locale: hu-HU (hu_HU); Calc: CL
(In reply to Aron Budea from comment #6)
> Strange, it looks fine with the below daily build in Windows 7. Somehow I
> doubt this got magically fixed between 11-14 and 11-17...
> Stuart, which version did you use for testing?
Version: 18.104.22.168.alpha1+ (and several more over last couple builds)
Build ID: 0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; Layout Engine: new;
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-19_23:33:29
Locale: en-US (en_US); Calc: CL
Version: 22.214.171.124 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default;
Locale: en-US (en_US); Calc: group
The extracted sample WMF opens just fine into Draw (or the full document into Writer)--issue is with export to PDF where it drops elements from the image in a consistent result as to what is lost for each image--so either a buffer issue, or a formatting issue with the WMF/EMF.
I tried again, from Draw this time, and the PDF I exported looks fine (yesterday I tried with the document from Writer). Something isn't entirely consistent here.
On Linux, I find that the bug disappeared somewhere in the 43all
bibisect repository. A reverse bibisect should be possible, if
anybody happens to care.
The bug reappeared somewhere between
commit s-h source committed
-------- -------- -------------------
4476c83f 26925066 2016-02-16 10:19:30 no bug
5d480e64 a042951a 2016-05-26 01:18:00 yes bug
That is a range of 4309 commits which I do not have covered. I shall
leave it for somebody with less-broken bibisect repositories than mine
to finish the job.
This seems to have begun at the below commit.
Adding Cc: to Chris Sherlock; Could you possibly take a look at this one? Thanks
author Chris Sherlock <firstname.lastname@example.org> 2016-03-03 10:52:49 (GMT)
committer Chris Sherlock <email@example.com> 2016-03-04 18:23:15 (GMT)
commit 6381d26d73c614681601fda4a49c96e11a0e6f06 (patch)
parent c788f63726df3340e787bb92477d7ad31e7bc952 (diff)
tdf#79679 vcl: dashed lines show as solid lines when importing EMF files
fa93ba2be0b1745c9e24150a9550e245e2777142 is the first bad commit
Author: Norbert Thiebaud <firstname.lastname@example.org>
Date: Wed Mar 9 09:12:54 2016 -0800
git bisect log
# bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source sha:60b74fe1775e647545d2da1fcc58a4c63ec18aa5
# good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source sha:49c2b9808df8a6b197dec666dfc0cda6321a4306
git bisect start 'origin/master' 'oldest'
# good: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source sha:c0da1080b61a1d51654fc34fdaeba373226065ff
git bisect good 38f37b8ec1a2d199bb957cfd2581df7d1b273b74
# bad: [11ae494d8c566f23e0ef84ba0cc25fb1388b67f7] source sha:470cfa9860232ab70e017e6084d80f80d469555c
git bisect bad 11ae494d8c566f23e0ef84ba0cc25fb1388b67f7
# bad: [d247d25062e6cc4afccdc3c4be84a2b98523b36a] source sha:150c1dcab007dd8acc1551791f42eef692f9e531
git bisect bad d247d25062e6cc4afccdc3c4be84a2b98523b36a
# bad: [dc23450cfb87b61fcbd905a7079d8a0d32759e6b] source sha:5c1234eac2b9f3a3ea032e4828a15bedca6b9ebe
git bisect bad dc23450cfb87b61fcbd905a7079d8a0d32759e6b
# good: [2b75279dd1a9671b07feaa00b25faa59a7056258] source sha:b1d9fe788e635619b379627abebeacd270ca7770
git bisect good 2b75279dd1a9671b07feaa00b25faa59a7056258
# bad: [279488432485bfea69e420aa9655e49bd6eb6bfd] source sha:2491b3217677d51ff3b4ee1a04fcde7a3b8f52a9
git bisect bad 279488432485bfea69e420aa9655e49bd6eb6bfd
# good: [c740b5e29a7b219670ddd5fa40569ad1d099fd54] source sha:1fd781e7cd33f325ec7e467ecd49e0cb6ff4762b
git bisect good c740b5e29a7b219670ddd5fa40569ad1d099fd54
# good: [30fbabb387891d3b8d8157ceb9108c62b183c960] source sha:3cefd33eb54d355d21f3541963ad1e89793c95f1
git bisect good 30fbabb387891d3b8d8157ceb9108c62b183c960
# good: [cac836f4ea138476c9d8aa75e5c89bf32e91dd53] source sha:cd9a5cf4312a2dc0c1ecbf682c67ca08862cdde0
git bisect good cac836f4ea138476c9d8aa75e5c89bf32e91dd53
# bad: [6a8aa0eddeb57c0cf135205161f56d4a616fd69f] source sha:58bef396cfcdd2c861d261e5b6fa68a859ff653d
git bisect bad 6a8aa0eddeb57c0cf135205161f56d4a616fd69f
# bad: [bd29ccabfbc999b641e9a3e14761324d8e15a72a] source sha:e0331002d39244cf9c8944fe291d1d009f919eb5
git bisect bad bd29ccabfbc999b641e9a3e14761324d8e15a72a
# bad: [fa93ba2be0b1745c9e24150a9550e245e2777142] source sha:6381d26d73c614681601fda4a49c96e11a0e6f06
git bisect bad fa93ba2be0b1745c9e24150a9550e245e2777142
# good: [0885986ce40e1eac11069c7f60b13edcadcdf5d8] source sha:c788f63726df3340e787bb92477d7ad31e7bc952
git bisect good 0885986ce40e1eac11069c7f60b13edcadcdf5d8
# first bad commit: [fa93ba2be0b1745c9e24150a9550e245e2777142] source sha:6381d26d73c614681601fda4a49c96e11a0e6f06
Hello Xisco, *,
I have tried to reproduce your bug with
OS: Debian Testing AMD64
LO: Version: 126.96.36.199.beta1
CPU-Threads: 4; BS-Version: Linux 4.5; UI-Render: Standard; VCL: gtk2; Layout-Engine: neu;
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
(parallel installed, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel/Linux)
and cannot reproduce your bug. Would you be so kind to test it with a newer version of LO than 188.8.131.52.alpha1, please? Maybe it is fixed with beta1 so this bug can be closed then ... ;)
I've just tried in LibreOffice 5.3 beta1
Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; Layout Engine: new;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
and I still reproduce the problem
oh, this is interesting, I can reproduce the problem if I open the resulted pdf in evince, but not if I do in firefox or chrome
[13:48:46] <DennisRoczek> x1sc0: any particular liobo version? (i have only 5.2.2 installed atm)
[13:49:06] <x1sc0> DennisRoczek, you can reproduce it with that one too
[13:49:58] <DennisRoczek> ok, with tracker software's PDF X-Change Viewer does it work correctly, same with edge
[13:50:14] <DennisRoczek> or win10's "Reader"
[13:50:33] <x1sc0> can you put a comment on the bug?
[13:50:52] x1sc0 is thinking of closing this
it seems it's only reproduced using Evince.
Closing this as RESOLVED NOTOURBUG
in MS edge / Win10's "Reader" (i guess same engine) it is NOT working: the arrows are not shown as in the comparison pdf. :-(
(In reply to Xisco Faulí from comment #15)
> it seems it's only reproduced using Evince.
> Closing this as RESOLVED NOTOURBUG
Xisco,I bisected this on windows with adobe reader...
Using Inkscape 0.91 if I import the PDF and choose the Poppler based import, portions of the image are lost--but if I use "native" Inkscape PDF import the entire image is rendered including the center line and the arrowed lines coming from "Object user 2"
So, in addition to Inkscape (when not using Poppler), I can confirm correct rendering in the PDF viewer in both FireFox and Chrome--as well as the InFix PDF editor and the TexWorks viewer all render the entire WMF, as extracted in comment 4, when it is exported from LibreOffice 5.3.0 Draw or Writer or Impress to PDF.
Also confirm that Adobe Reader 15/Acrobat Pro 9.5.5, Windows Explorer (preview), MS Edge, MS PDF Reader, and the Imagmagick IMdisplay on Windows--and likewise the Evince document viewer on Linux--all do not render the entire WMF as exported to PDF. Dropping the dashed center line and several arrows pointing from the "Object user 2" element.
So, the question is what are we doing wrong in our export filter for WMF metafile that prevents some common PDF viewers from handling our PDF? Is our export filter Poppler based?
The various print to PDF--OS or gs/ps based--all produce full representation of the WMF in PDF, it is just our Export-to-PDF that is having the issue.
attachment 85495 [details] seems to be affected by the same problem.
(In reply to Xisco Faulí from comment #19)
> attachment 85495 [details] seems to be affected by the same problem.
Not so sure it is the same--but probably related...
With that OOXML .PPTX document, opened and exported as individual slides from Impress 5.3.0b1, the elements that I see not rendering with some PDF viewers are both JPEG with CMYK color space.
The Delphi IMM (image5.jpeg), and the One Surface One GeoWay (image3.jpeg)
ImageMagick identify of the .PPTX zip archive -> ppt/media contents...
image1.png PNG 679x187 679x187+0+0 8-bit sRGB 256c 18.2KB 0.000u 0:00.000
image2.png PNG 238x108 238x108+0+0 8-bit sRGB 7.54KB 0.000u 0:00.000
image3.jpeg JPEG 346x148 346x148+0+0 8-bit CMYK 48.3KB 0.016u 0:00.015
image4.jpeg JPEG 385x176 385x176+0+0 8-bit sRGB 19.8KB 0.000u 0:00.000
image5.jpeg JPEG 886x544 886x544+0+0 8-bit CMYK 126KB 0.000u 0:00.000
Chrome and FireFox both render the CMYK images in our PDF. But the same list of PDF viewers that had issues with WMF have issues with these two CMYK images in exported PDF.
(In reply to V Stuart Foote from comment #20)
> Chrome and FireFox both render the CMYK images in our PDF. But the same list
> of PDF viewers that had issues with WMF have issues with these two CMYK
> images in exported PDF.
Actually only FireFox handled our PDF CMYK color correctly, Chrome showed the image but in a weird grayscale with some loss of detail.
*** Bug 113756 has been marked as a duplicate of this bug. ***
@Bartosz, I thought you might be interested in this one...
Still reproducible in
Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Repro LO 6.3+ in Windows opening PDF in Adobe Reader. PDF-Exchange is fine.