Description: When a PDF image is used for the background of a draw document and the document is then exported as PDF, the background is included in the PDF document as a low resolution bitmap, rather than as a vector image. This is very much undesirable: - the possibility to cut/copy text is lost - the resolution is poor (96dpi) - the vector quality of the image is lost - in some cases the resulting PDF file gets larger than it could (this is limited by the very poor resolution of the bitmap, though) Note that using PDF images as background represents a frequently adopted workflow for filling in forms that have been made available in PDF, but not as PDF forms. Steps to Reproduce: 1. Open libreoffice draw 2. Insert as the background image a PDF file 3. Export to PDF 4. Open the resulting PDF file with a viewer or use some utility such as pdfimages to export the bitmaps that are present in the PDF file Actual Results: The background image is present in the PDF file as a 96dpi bitmap Expected Results: The background image should be maintained in vector format if it is in vector format to start with. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: StartModule [Information guessed from browser] OS: Linux (All) OS is 64bit: yes Version: 7.3.4.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.18; UI render: default; VCL: kf5 (cairo+xcb) Locale: it-IT (en_US.UTF-8); UI: en-US 7.3.4-2 Calc: threaded
IMHO not a bug, rather a limitation of the pdfium based "insert as image" filter import. Something different, e.g. using the graphic objects PDF vector data rather than the raster output, would be an enhancement. Undocumented, but for 7.2 builds you *can* control the pdfium based insert filter by setting env variable: PDFIMPORT_RESOLUTION_DPI default is the 96dpi noted, but you can take the resolution as high as is needed for work on the canvas and for 7.3 was further reworked for export/printing at the higher resolution set. helpful when working at full page scaling for the image, i.e. as page background. =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/113223 [2] https://gerrit.libreoffice.org/c/core/+/121087
The Wiki has info on setting env variable including PDFIMPORT_RESOLUTION_DPI, but not much about its function. @Seth? Something needed for Help, or maybe in the Draw guide or Getting started guide...
If you use `insert → image` from the menu, and you insert the PDF image in the page rather than as the background of the page, then the PDF export works properly maintaining the vector nature of the image. Hence, the behavior for the background image is at best not consistent and from a user point of view it is really quite confusing why `Page → Set image as background` should use pdfium in a different way from `insert → image`. Furthermore, if you insert an SVG image as the background, then the PDF export also works properly. So again there is an inconsistency in how LibO treats two different vector formats. Because SVG support is in some cases better than PDF support (maybe in part due to the pdfium migration, that brought much more faithful conversion of PDF files to bitmaps but otherwise weakened the treatment of PDF files as a vector format) I would like to take the occasion to suggest readers who may stumble in this same issue or in other issues with PDF import to consider conversion to SVG before the import (there are many fine open source tools for that, from `dvisvgm` to `inkscape`). Is there a [META] bug for PDF image management? I see 113122. Would that be appropriate as a tracking bug for this?
(In reply to Callegar from comment #3) > If you use `insert → image` from the menu, and you insert the PDF image in > the page rather than as the background of the page, then the PDF export > works properly maintaining the vector nature of the image. Hence, the > behavior for the background image is at best not consistent and from a user > point of view it is really quite confusing why `Page → Set image as > background` should use pdfium in a different way from `insert → image`. > > Furthermore, if you insert an SVG image as the background, then the PDF > export also works properly. So again there is an inconsistency in how LibO > treats two different vector formats. Reproduced as described. Right click > Page > Background > PDF results in bad bitmap resolution when exported, whereas Insert > Image > PDF keeps it as vector. Interestingly, when trying to create a sample document, I also noticed that if I insert the PDF as a page background first, and then on another page insert the same PDF as an image, I get bad resolution on _both_ in the PDF export. So to compare image insert vs page background, work on two files separately. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 53c5d570cab036b23f4969b858a648c8f0c24f93 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
(In reply to Stéphane Guillou (stragu) from comment #4) And if you set the PDFIMPORT_RESOLUTION_DPI environment variable?
Dear Callegar, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Jaume Pujantell committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/59f7c0491aab89dd5d746407f8089af01cd12542 tdf#150076 embed background pdf It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.