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
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.
Sorry wrong META, PDF Insert (bug 114233) not Import (bug 99746)
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).
(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.
@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?
(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.
Yep, the dynamic approach would be great :-) - but later, needs some planning...
*** Bug 113441 has been marked as a duplicate of this bug. ***
*** Bug 121450 has been marked as a duplicate of this bug. ***
Hello, when will the 96 dpi resolution problem be resolved ? Have there been any developments since June 2018 ? Thanks Hans-Werner
*** Bug 124765 has been marked as a duplicate of this bug. ***
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.
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
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.
(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
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 :-)
*** Bug 131026 has been marked as a duplicate of this bug. ***
*** Bug 140449 has been marked as a duplicate of this bug. ***
For the record, since a lot of dupes are about lower resolution PDF import since 5.4, adding the commit causing this regression for reference: https://cgit.freedesktop.org/libreoffice/core/commit/?id=6657d52417295265367cf3ffe5832b60e3c38011 author Miklos Vajna <vmiklos@collabora.co.uk> 2017-02-13 17:05:19 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2017-02-13 16:54:04 +0000 vcl pdf import: use pdfium instead of draw_pdf_import
So at 7.2 [1] we now have an os environment variable that when set will override the default 96dpi that had been used for the pdfium based import as image filter. PDFIMPORT_RESOLUTION_DPI and for current trunk against 7.3.0, that has been extended to printing/export [2] What remains missing is a way to conveneiently set it from within LO's UI. Also these are not documented. Should something go into the 7.2 release notes? =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/113223 [2] https://gerrit.libreoffice.org/c/core/+/121087
Should this have the filter:pdf keyword?
(In reply to Graham Perrin from comment #21) > Should this have the filter:pdf keyword? probably not, the PDF-Insert alias of bug 114233 has it covered...
*** Bug 124539 has been marked as a duplicate of this bug. ***