Created attachment 128864 [details] sample Steps: 1. Open the attached file 2. Export it to PDF Observed behaviour: Some of the arrows in the second page are lost Reproduced in Version: 5.3.0.0.alpha1+ Build ID: 757a60d01dd152aadab2ba3c8224252481ce8a88 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group but not in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e
Actually I've just realized all the text after the shape is lost too
Created attachment 128865 [details] comparison
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? Version: 5.3.0.0.alpha1+ 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: 5.3.0.0.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: 5.2.3.3 (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 <chris.sherlock79@gmail.com> 2016-03-03 10:52:49 (GMT) committer Chris Sherlock <chris.sherlock79@gmail.com> 2016-03-04 18:23:15 (GMT) commit 6381d26d73c614681601fda4a49c96e11a0e6f06 (patch) tree 2ef7c86fa0490ef6b3cddb6ebb49e2b29309aba3 parent c788f63726df3340e787bb92477d7ad31e7bc952 (diff) tdf#79679 vcl: dashed lines show as solid lines when importing EMF files fa93ba2be0b1745c9e24150a9550e245e2777142 is the first bad commit commit fa93ba2be0b1745c9e24150a9550e245e2777142 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Mar 9 09:12:54 2016 -0800 source 6381d26d73c614681601fda4a49c96e11a0e6f06 git bisect log # bad: [6380ca07b05f68dedcaa379302cfe1fa478571c4] source 60b74fe1775e647545d2da1fcc58a4c63ec18aa5 # good: [1f670510f08cb800cbae2a1dd6ea70d3542e4721] source 49c2b9808df8a6b197dec666dfc0cda6321a4306 git bisect start 'origin/master' 'oldest' # good: [38f37b8ec1a2d199bb957cfd2581df7d1b273b74] source c0da1080b61a1d51654fc34fdaeba373226065ff git bisect good 38f37b8ec1a2d199bb957cfd2581df7d1b273b74 # bad: [11ae494d8c566f23e0ef84ba0cc25fb1388b67f7] source 470cfa9860232ab70e017e6084d80f80d469555c git bisect bad 11ae494d8c566f23e0ef84ba0cc25fb1388b67f7 # bad: [d247d25062e6cc4afccdc3c4be84a2b98523b36a] source 150c1dcab007dd8acc1551791f42eef692f9e531 git bisect bad d247d25062e6cc4afccdc3c4be84a2b98523b36a # bad: [dc23450cfb87b61fcbd905a7079d8a0d32759e6b] source 5c1234eac2b9f3a3ea032e4828a15bedca6b9ebe git bisect bad dc23450cfb87b61fcbd905a7079d8a0d32759e6b # good: [2b75279dd1a9671b07feaa00b25faa59a7056258] source b1d9fe788e635619b379627abebeacd270ca7770 git bisect good 2b75279dd1a9671b07feaa00b25faa59a7056258 # bad: [279488432485bfea69e420aa9655e49bd6eb6bfd] source 2491b3217677d51ff3b4ee1a04fcde7a3b8f52a9 git bisect bad 279488432485bfea69e420aa9655e49bd6eb6bfd # good: [c740b5e29a7b219670ddd5fa40569ad1d099fd54] source 1fd781e7cd33f325ec7e467ecd49e0cb6ff4762b git bisect good c740b5e29a7b219670ddd5fa40569ad1d099fd54 # good: [30fbabb387891d3b8d8157ceb9108c62b183c960] source 3cefd33eb54d355d21f3541963ad1e89793c95f1 git bisect good 30fbabb387891d3b8d8157ceb9108c62b183c960 # good: [cac836f4ea138476c9d8aa75e5c89bf32e91dd53] source cd9a5cf4312a2dc0c1ecbf682c67ca08862cdde0 git bisect good cac836f4ea138476c9d8aa75e5c89bf32e91dd53 # bad: [6a8aa0eddeb57c0cf135205161f56d4a616fd69f] source 58bef396cfcdd2c861d261e5b6fa68a859ff653d git bisect bad 6a8aa0eddeb57c0cf135205161f56d4a616fd69f # bad: [bd29ccabfbc999b641e9a3e14761324d8e15a72a] source e0331002d39244cf9c8944fe291d1d009f919eb5 git bisect bad bd29ccabfbc999b641e9a3e14761324d8e15a72a # bad: [fa93ba2be0b1745c9e24150a9550e245e2777142] source 6381d26d73c614681601fda4a49c96e11a0e6f06 git bisect bad fa93ba2be0b1745c9e24150a9550e245e2777142 # good: [0885986ce40e1eac11069c7f60b13edcadcdf5d8] source c788f63726df3340e787bb92477d7ad31e7bc952 git bisect good 0885986ce40e1eac11069c7f60b13edcadcdf5d8 # first bad commit: [fa93ba2be0b1745c9e24150a9550e245e2777142] source 6381d26d73c614681601fda4a49c96e11a0e6f06
Hello Xisco, *, I have tried to reproduce your bug with OS: Debian Testing AMD64 LO: Version: 5.3.0.0.beta1 Build-ID: 690f553ecb3efd19143acbf01f3af4e289e94536 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 5.3.0.0.alpha1, please? Maybe it is fixed with beta1 so this bug can be closed then ... ;) TIA Thomas.
I've just tried in LibreOffice 5.3 beta1 Version: 5.3.0.0.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
correction: 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 Version: 6.1.0.0.alpha0+ 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! Warm Regards, QA Team MassPing-UntouchedBug
Repro LO 6.3+ in Windows opening PDF in Adobe Reader. PDF-Exchange is fine.
Repro 6.4+ in Windows opening PDF in Adobe Reader. PDF-Exchange and Master PDF Editor adn Firefox open it fine.
*** Bug 136873 has been marked as a duplicate of this bug. ***
Unable to reproduce it on: Version: 7.3.2.2 / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Confirmed with Version: 7.2.4.1 (x64) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded 🤣 and Edge,vivaldi+firefox (92? latest), xchange
With tricky bugs like this one, it's important what one tested. This remains as it is in the title: NOK: Evince, Xreader, Adobe reader, Edge (OK: PDF-Xchange, Master PDF Editor, Firefox) So if you tested OK with PDF-Xchange, Firefox... you didn't confirm bug was resolved, unless you test with Adobe, Xreader... which still open wrong, tested with 7.4+. And something like that happens also in bug 148680. I set New again.