When I try to export http://imgur.com/izBTWSb.jpg as a PDF I instead get https://i.imgur.com/FyIvCeA.jpg. I have attempted the default profile fix (https://ask.libreoffice.org/en/question/58416/writer-keeps-changing-default-indents-to-30/?answer=58449#post-id-58449).
Hi spartanhooah, Thanks for the report. If I paste the jpg in either a writer or a drawing document and export that to PDF, it shows up fine. In 5.0.2.2. on Linux. Can you please give clear steps of how you use the jpg and do the export? Best - Cor
Steps: 1) Take a screenshot from Firefox. 2) Paste into paint.net 4.0.6. 3) Select just the part I want. 4) Paste into new Writer document. 5) Export as PDF. 6) Open with SumatraPDF. Interestingly, Sumatra is the only program that actually displayed anything. The Windows 10 Reader app, Edge, and Firefox 41 all displayed a blank page.
Thanks - I see no problem. But have no SumatraPDF.
(In reply to spartanhooah from comment #2) > Steps: > 1) Take a screenshot from Firefox. > 2) Paste into paint.net 4.0.6. > 3) Select just the part I want. > 4) Paste into new Writer document. > 5) Export as PDF. > 6) Open with SumatraPDF. > > Interestingly, Sumatra is the only program that actually displayed anything. > The Windows 10 Reader app, Edge, and Firefox 41 all displayed a blank page. I don't have paint.net, but I have SumatraPDF. I simply right-clicked - copied image from http://imgur.com/izBTWSb.jpg, pasted it to Writer and exported to PDF. SumatraPDF displayed it just fine. Does it display messed up for you, if you do as I did? Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI) SumatraPDF 3.0
Yes, it still shows messed up if I copy it from imgur.
No problem in Version: 5.1.0.0.alpha1+ Build ID: 8273350ff48f198efc9dc9c5de5519b8cbdc0cb3 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-10-07_05:54:26 Please attach test writer file.
*** Bug 94944 has been marked as a duplicate of this bug. ***
*** Bug 94986 has been marked as a duplicate of this bug. ***
Bug 94986 contains an example document and PDF output that may help to reproduce the issue.
(In reply to ckakman from comment #9) > Bug 94986 contains an example document and PDF output that may help to > reproduce the issue. No problem for me, when I export a PDF from the document in attachment 119542 [details] Win 7 Pro 64-bit, Version: 5.0.2.2 (x64) Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Locale: fi-FI (fi_FI)
Hi, Same problem here with Libre office 5.0.2 on Windows 7 64. Images are corrupted (just some artefacts) and color disappear.
We need a test file, guys..
pascal: do you get the bad result with attachment 119542 [details]?
When I disabled rendering using OpenGL (Settings > LibreOffice > View > Use OpenGL for all rendering) images were correctly rendering in the produced PDF file. You can try the file attached to the duplicate Bug 94986 with that option enabled.
spartanhooah: do you get a correct result after disabling Options > LibreOffice > View > Use OpenGL for all rendering
Yes, it appears that disabling OpenGL fixes this problem (in addition to at least one other).
Ok we have enough confirmation to set this to NEW. I'll add this to the OpenGL metabug.
*** Bug 95368 has been marked as a duplicate of this bug. ***
Looks like an interesting row-stride problem.
Hi spartanhooah! Interesting report. On MacOSX version, if I paste a random picture to Writer or Impress, the output of PDF is without problems. (MacOSX 10.8.5 / LO 4.4.6.3 + LO 5.1.0.0-a) The same is for Linux version (4.4.5.2) May be this is a graphic stack problem in Your OS?
Bookman900, thanks, but it looks like this is an OpenGL-related thing, as Beluga has stated.
*** Bug 95855 has been marked as a duplicate of this bug. ***
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=82e0c38e1205a3c8a70234a95ca33ab1400fbe57 tdf#94739 use GetScanlineSize instead of calculating it It will be available in 5.2.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.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ec558395c70db9d493e705566673f7e7c349a7a&h=libreoffice-5-1 tdf#94739 use GetScanlineSize instead of calculating it It will be available in 5.1.0.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.
GL disabled in 5.0.x as of now -> closed.
Hi Michael, Really good that the immediate problem is resolved! But before closing this issue as Resolved, it looks logic that first the images behave correct with OpenGL enabled. I assume it is not the intention to move OpenGL-use to some unstable setting? We can of course also change the summary/porte of this bug to some desired change in the setting, but that then is more QA-BugZilla-playing IMO. What do you think? Cheers, Cor
Hmm, but if you refer to the patch of comment#24, that makes use of a different way to render the images for PDF export, then of course...
Pushed this to gerrit for -5-0 too (if that's what your comment means Cor) ? https://gerrit.libreoffice.org/20595 tdf#94739 use GetScanlineSize instead of calculating it So - re-closing. Would love the bug to be verified in master or -5-1 - in case it persists =)
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ffe150ce903d9cdc62c25ad3437e61d24ede17d6&h=libreoffice-5-0 tdf#94739 use GetScanlineSize instead of calculating it It will be available in 5.0.5. 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.
*** Bug 96455 has been marked as a duplicate of this bug. ***
and now they are distorted diagonally when opengl rendering is not enabled
see bug 96653 for that problem