Bug 113441 - Inserted PDFs - loss of sharpness since LO 5.4
Summary: Inserted PDFs - loss of sharpness since LO 5.4
Status: RESOLVED DUPLICATE of bug 115811
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.1 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, implementationError
Depends on:
Blocks: PDF-Insert
  Show dependency treegraph
 
Reported: 2017-10-25 11:19 UTC by Hans-Werner
Modified: 2021-08-01 05:50 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
WRITER document with inserted PDFs (2.31 MB, application/vnd.oasis.opendocument.text)
2017-10-25 11:19 UTC, Hans-Werner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Werner 2017-10-25 11:19:27 UTC
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)
Comment 1 Thomas Krumbein 2017-10-25 11:51:35 UTC
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.
Comment 2 Xisco Faulí 2017-10-25 13:19:38 UTC
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?
Comment 3 Miklos Vajna 2017-10-25 14:12:34 UTC
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.
Comment 4 QA Administrators 2018-11-25 03:40:53 UTC Comment hidden (obsolete)
Comment 5 Hans-Werner 2018-11-25 08:51:24 UTC
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
Comment 6 Roman Kuznetsov 2018-11-25 19:01:46 UTC
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
Comment 7 V Stuart Foote 2018-11-25 20:09:50 UTC

*** This bug has been marked as a duplicate of bug 115811 ***