Created attachment 137282 [details] WRITER document with inserted PDFs Hello, if opening the attached file "BremsModul.odt" (BremsModul = BrakingModule for "Märklin" model trains) using "WRITER LO 5.3.X" then everything is fine. If opening the same file using "WRITER LO 5.4.X" then a loss of image sharpness is quite clearly. All the inserted PDFs are created by using the "Export as PDF" feature of CALC/DRAW. Some more test results using "LO 5.3.6.1" and "LO 5.4.3.1": Export as PDF: LO 5.3.6.1 -> sharp | LO 5.4.3.1 -> sharp Print Preview: LO 5.3.6.1 -> sharp | LO 5.4.3.1 -> unsharp Print: LO 5.3.6.1 -> sharp | LO 5.4.3.1 -> unsharp Print (using "PDF24" as printer driver): LO 5.3.6.1 -> sharp | LO 5.4.3.1 -> unsharp Operating system: "Windows 7 Home Premium 64-bit" I hope the above mentioned behaviour of "LO 5.3.X" will be back soon in "LO 5.4.X" or newer, because it's very fine not to have to think about the PDF source and being able in WRITER to resize/rescale up and down the inserted PDF images without loss of sharpness. Best regards Hans-Werner BTW: BremsModul = BrakingModule (for "Märklin" model trains)
Confirmed for Windows 10 and Linux Mint 16.4 ( Ubuntu). both in LO 5.4.x as in LO 6.0.0.alpha. Pictures are really blurred.
Regression introduced by: author Miklos Vajna <vmiklos@collabora.co.uk> 2017-02-13 16:05:19 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2017-02-13 16:54:04 (GMT) commit 6657d52417295265367cf3ffe5832b60e3c38011 (patch) tree a664018f1eb611c88d8d73fd3b0241090ec36f8d parent 7c9c6a4425b679596acae6f67ee8ac5f3d98bd6e (diff) vcl pdf import: use pdfium instead of draw_pdf_import Replace creating a full Draw component with direct pdfium library calls. This also means that the result is now a bitmap, not a metafile for now. Also decouple HAVE_FEATURE_PDFIMPORT and HAVE_FEATURE_PDFIUM, the first is the "import PDF into Draw" feature, the second is the "insert PDF as image" feature. Bisected with: bibisect-linux-64-5.4 Adding Cc: to Miklos Vajna @Miklos, since this is an issue in PDFium, should it be reported to their bugtracker instead?
I'm not sure right now. In case the "sharpness" is because we render the PDF into a bitmap with pdfium, and the size of the bitmap is too small (because the PDF reports a small logic size), then this is not a bug in pdfium itself, but in our integration. However, rendering via pdfium is a new feature, so I think this is rather an implementation error to fix, than an easy regression to address. One way to address this could be to not render the pdf immediately on import, rather only when it gets displayed, and then we can work with the user-defined size of the picture, not the in-PDF logic size. But that would probably slow down scrolling, so it'll also need a cache -- so needs some thinking first.
** 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
Hello, the bug ist still present. Tested with the attachment of this bug report. [1] NOT BLURRED, BEST RESULT - BUG NOT PRESENT Version: 5.3.7.2 (x64) Build-ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: CL [2] VERY MUCH BLURRED - BUG STILL PRESENT Version: 6.0.7.3 (x64) Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: CL Version: 6.1.3.2 (x64) Build-ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU-Threads: 4; BS: Windows 6.1; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: group threaded Version: 6.2.0.0.beta1 (x64) Build-ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded Best regards Hans-Werner
still repro in Version: 6.2.0.0.beta1 (x64) Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: CL
*** This bug has been marked as a duplicate of bug 115811 ***