Bug 115811 - pdfium based ipdf defaults to 96 dpi for image, need an option for higher resolution
Summary: pdfium based ipdf defaults to 96 dpi for image, need an option for higher res...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 113441 121450 124765 131026 (view as bug list)
Depends on:
Blocks: PDF-Insert Image-DPI
  Show dependency treegraph
 
Reported: 2018-02-17 18:40 UTC by V Stuart Foote
Modified: 2020-09-18 17:57 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2018-02-17 18:40:24 UTC
The ipdf filter looks to default to 96 dpi resolution [1] when importing from a PDF. This is OK, but ability to increase the resolution (and size) of the imported PNG rendering would be helpful. 96 dpi is just too low a resolution when dealing with import of full pages from a PDF.  Seems providing 300 or 600 dpi would be helpful and allow for quality printout/export from the resulting ODF.

=-ref-=
https://opengrok.libreoffice.org/xref/core/vcl/source/filter/ipdf/pdfread.cxx?a=true&h=59#53
Comment 1 V Stuart Foote 2018-02-17 18:44:37 UTC
Guess if we were to do something for bug 112426, that would also be the place to adjust the resolution used for the inserted image.
Comment 2 V Stuart Foote 2018-02-17 19:04:18 UTC
Sorry wrong META, PDF Insert (bug 114233) not Import (bug 99746)
Comment 3 Miklos Vajna 2018-02-19 09:53:11 UTC
Export to PDF is not affected, there the original vector PDF is reused.

For other cases it would be indeed nice to render the PDF much later when it's clear what DPI would match the user's need (depending on the logical size of the image in the document + perhaps also depending on the zoom level, as e.g. SVG does).
Comment 4 V Stuart Foote 2018-02-19 15:48:10 UTC
(In reply to Miklos Vajna from comment #3)
> Export to PDF is not affected, there the original vector PDF is reused.
> 

Yes sorry, forgot that the source PDF is retained and is reused with an export to PDF. 

In testing used a ghostscript based printer to print to PDF, which does not use the PDF, and so needs the higher resolution bitmap/PNG to work with.
Comment 5 V Stuart Foote 2018-06-12 13:59:43 UTC
@Ashod, Kendy

https://gerrit.libreoffice.org/#/c/54786

Was there more to be done for user to be able to select to render "preview" bitmap at higher than 96 dpi?
Comment 6 Ashod Nakashian 2018-06-12 14:05:11 UTC
(In reply to V Stuart Foote from comment #5)
> @Ashod, Kendy
> 
> https://gerrit.libreoffice.org/#/c/54786
> 
> Was there more to be done for user to be able to select to render "preview"
> bitmap at higher than 96 dpi?

Happy to know this issue is tracked. Been meaning to file one myself.

At the moment this isn't supported, but one idea is to make this dynamic. That is, re-render the page in higher DPI as the user zooms in. Obviously this is a much bigger task than just allowing the user the ability to render at desired DPI (say at the point of opening/inserting a PDF), but ultimately it will give the best user-experience.

The other options are 1) add a user setting for all PDF imports to be at a desired DPI, or 2) pop-up an import settings window when the user opens/inserts a PDF that prompts the user to choose the desired DPI.

As a user, I'd certainly prefer the dynamic rendering with zoom-in and zoom-out, in spite of the higher cost of implementing it.
Comment 7 Jan Holesovsky 2018-06-12 20:29:18 UTC
Yep, the dynamic approach would be great :-) - but later, needs some planning...
Comment 8 V Stuart Foote 2018-11-25 20:09:50 UTC
*** Bug 113441 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2018-11-25 20:11:54 UTC
*** Bug 121450 has been marked as a duplicate of this bug. ***
Comment 10 Hans-Werner 2019-07-15 14:00:55 UTC
Hello,
when will the 96 dpi resolution problem be resolved ? Have there been any developments since June 2018 ?
Thanks
Hans-Werner
Comment 11 Buovjaga 2020-05-06 17:36:04 UTC
*** Bug 124765 has been marked as a duplicate of this bug. ***
Comment 12 sergio.callegari 2020-09-08 17:30:43 UTC
Please, do not add the unneeded complexity of having the user prompted for what resolution should be used when importing vector images for showing them onto the screen.  The vector image can be rendered at any given resolution and ideally LibO should know what resolution is needed and be capable to re-do the rendering when this requirement changes (e.g., when one rescales the images or zooms in on it) or moves to presentation mode in impress.
Comment 13 V Stuart Foote 2020-09-08 18:10:50 UTC
LibreOffice ipdf insert filter does not render PDF to vector, it generates a lowres 96 dpi raster of the 1st page of selected PDF.

The current default 96 dpi bitmap rendering is performant, but it is of low quality/pixelated when a full page image is rendered at full page size. Setting a more reasonable default of 300 dpi for the resulting BMP meta would make it more appealing for screen use. 

If rework of the pdfium based ipdf filter receives a user interaction to select the page(s) to be inserted, then it is reasonable to also specify the resolution of the resulting bitmap (or the sampling framework PDFium uses) to rasterize the PDF.

Likewise, should needed additional dev work on the filter be done to support rendering to vector objects on canvas, the resolution of the filter will NOT necessarily be at the full resolution of the source PDF--it could be, but the extra precision would come at a performance price and is not normally needed. Some user interaction/choice for fidelity would be appropriate. But, that is an implementation decision for the devs.


As would be handling the PDF page selection/extraction via a dialog able to eliminate holding the full source PDF with the ODF archive--pointed out as a potential privacy issue in bug 131768
Comment 14 Jan Holesovsky 2020-09-09 07:45:40 UTC
Stuart: The problem here is that this code is used not only for insertion of a PDF (and thus showing just the 1st page), but also for rendering all the pages in PDFs in the Online.

Increasing the DPI to 300 would require 9x more memory for the renders, which is too much; so the dynamic approach outlined in the comment 3 and comment 6 would be really ideal.

Adding Quikee who is now working on various PDF related improvements, and previously he reworked the swap in/out mechanism, maybe he'll have an idea how to do this with a reasonable effort.
Comment 15 V Stuart Foote 2020-09-09 13:08:47 UTC
(In reply to Jan Holesovsky from comment #14)
> Stuart: The problem here is that this code is used not only for insertion of
> a PDF (and thus showing just the 1st page), but also for rendering all the
> pages in PDFs in the Online.
> 
> Increasing the DPI to 300 would require 9x more memory for the renders,
> which is too much; so the dynamic approach outlined in the comment 3 and
> comment 6 would be really ideal.
> 
> Adding Quikee who is now working on various PDF related improvements, and
> previously he reworked the swap in/out mechanism, maybe he'll have an idea
> how to do this with a reasonable effort.

OK, reasonable for LO Online concerns. But given that the ipdf insertion that resolved bug 89727 is treated as an "insertion of a PDF page as an image" has it ever made sense to keep the *entire* source PDF around? If just the PDF source page is carried in ODF archive couldn't the resolution of the preview be set as high as requested/needed for good screen appearance. 

For the insert as image handling, why not reduce the overhead; i.e. first reduce the source PDF to just the target page, and render only that to canvas (retaining only the reduced PDF for printing). 

Benefit of avoiding the potential privacy/security concerns of bug 131768
Comment 16 Jan Holesovsky 2020-09-09 13:41:24 UTC
Stuart: So that's a different issue; yes, when inserted, the pdfium can be used to use just the 1st page out of that and keep that reduced PDF as the vector data.  But this is orthogonal to the preview resolution generation :-)
Comment 17 Buovjaga 2020-09-18 17:57:06 UTC
*** Bug 131026 has been marked as a duplicate of this bug. ***