Description: In LibODev 7.0 Beta 1 draw and impress, PDF images are imported with a wrong size. Example a PDF image created with inkscape that is 100 mm times 100 mm, once imported appears as 190 mm times 190 mm (I suppose because it gets limited to the in-margin area of an A4 paper) and pressing "original size" brings it to 362 mm times 362 mm. The same image, imported in LibO 6.4 is 100 mm times 100 mm. Steps to Reproduce: 1. Open draw 2. Import a PDF image Actual Results: Image is imported with correct proportions but a wrong size Expected Results: Image should be imported at the correct size Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: DrawingDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
Imported or Inserted? Completely different actions. Opening with Draw--is "Imported" Inserting as Image into Draw, Impress, Writer or Calc is "Inserted"
My mistake: inserted
Not seeing an issue here. When we insert any image, we normally want the image to either fit within width in the frame/section we have selected active, or to have it fit within width of page margins as set. The pdfium based PDF insert follows this behavior--expanding to fit within frame, or within page margin--keeping image proportion and resizing as needed to fit width. => WFM
Not really, the default behavior has always been to /fit inside the margins/. Namely, when inserting an image, the size information stored in the image (either directly as in PDF or indirectly via the DPI in raster images) is compared with the available space. If the image is larger than the margins, it is fit to the margins, otherwise it is inserted at its size. It has never been the case that images that are already small enough to fit in the margins are enlarged to the drawing area. This is what is happening now and was not happening with LibO 6.x.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 161708 [details] Test PDF image to insert (100mm x 100mm)
Created attachment 161709 [details] Screenshot of image correctly inserted in LibO 6.4 draw
Created attachment 161710 [details] Screenshot of image inserted in LibO 7 beta draw at a too large size
I have attached a test case. To reproduce, it is sufficient to fire up LibO draw and use insert->image. In LibO 6.4 the image gets inserted correctly. The inserted image is 100mm x 100 mm as it should. In LibO 7 beta the image gets inserted at a too big size, namely it is scaled to the margins even if the original image was small enough to fit in the margin. There are also other minor problems. They will probably best be addressed in separate bugs, but I'd like to also mention them here just in case they can get fixed as side effects of fixing the principal issue: 1. When the image is scaled to the margins, its position is not aligned to the margins. 2. The resolution by which the pdf image is inserted visualizing a raster version of it for efficiency is too low. This is likely a side effect of LibO 7 beta scaling the image up. However, the same thing also happens in LibO 6.x if one inserts the image and then manually scales it up to a larger size. Because, LibO knows the original vector image, the bitmap should probably be automatically refreshed when the image is scaled, in order to get an appropriate resolution. 3. The original PDF image has no background. However, the inserted image has a solid white background. This is bug 106581.
Not only size but also type changes. LO6.4.5 has "image" and LO7.0.0beta1 has "svg". Tested with Version: 6.4.5.0.0+ (x64) Build ID: 70a2071ce91b71326659e645dd97996262ea309a CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (en_US); UI-Language: en-US Calc: CL and with Version: 7.0.0.0.beta1+ (x64) Build ID: 8c08eefeb512d4cbc86c4c5308d86a59bd232beb CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Vulkan; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL
Default handling (scale to margins) of the pdfium generated image has changed, but not sure that is a bug. IIU?C all images are scaled to margins on insertion. Otherwise, it is trivial to restore the inserted image to its original dimensions. Select the image context menu open 'Properties' on the 'Crop' tab, select the 'Original size' button 'OK" the dialog to apply. The image will resize to original drawn from the source PDF. Save to Flat ODF delivers the rendered PNG, and the original PDF in a Frame to hold it. IMNHO behavior fo the pdfium import filter has changed, WFM and NAB @Tomaž?
Oh crud! Sorry, I read insert and thought Writer and tested there as indicated--behavior is as expected. Behavior in Draw is as reported. And, the 'Original size' context menu action has lost linkage to the source PDF--its resize is not correct. Don't doubt Regina's SVG result--but on save to Flat ODG the source PDF remains along with the replacement PNG. The size for the graphic frame is enormous, and the Original size button action resizes to ~36cm--bearing no relation to the PDFs. So, yep have an issue with the handling in Draw, not present inserting PDF into the other modules.
(In reply to V Stuart Foote from comment #12) > Don't doubt Regina's SVG result-- It is about the type reported in the status bar, if the object is selected.
Bibisected to the following commit using repo bibisect-linux-64-7.0. Adding CC: to Kendy. https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ac2d66c78d6c080aabfa46157113684c2f3a3b0 author Jan Holesovsky <kendy@collabora.com> 2019-10-18 11:19:04 +0200 committer Tomaž Vajngerl <quikee@gmail.com> 2020-03-17 22:01:15 +0100 pdfium: Make Insert -> Image... use VectorGraphicData for PDF.
Quikee: Can you please have a look at some stage? Thank you!
*** Bug 141194 has been marked as a duplicate of this bug. ***
Even 6.4 seems to have some issues with this in a particular condition: If I open the document with LibO 6.4 it looks OK. If I export it to PDF via the LibO 6.4 export interface, the PDF is OK. However, if I try to export to PDF programmatically with this script: Dim oPropPDF(3) As New com.sun.star.beans.PropertyValue oPropPDF(0).Name="ExportNotesPages" oPropPDF(0).Value=true oPropPDF(1).Name="ExportBookmarks" oPropPDF(1).Value=false oPropPDF(2).Name="EmbedStandardFonts" oPropPDF(2).Value=true Dim oProp(3) As New com.sun.star.beans.PropertyValue oProp(0).Name="Overwrite" oProp(0).Value=true oProp(1).Name="FilterName" oProp(1).Value="impress_pdf_Export" oProp(2).Name="FilterData" oProp(2).Value=oPropPDF() oDoc.storeToURL(pdfURL,oProp()) then the PDF image and cropping is wrong in the exported PDF. I have been using this code for ages and I am pretty sure that it used to produce good PDFs out of this document in the past... However I would not be able to say how much in the past (autumn 2020 probably). Any clue?
(In reply to Callegar from comment #17) > Even 6.4 seems to have some issues with this in a particular condition: ... > Any clue? Yes, please open a separate bug report if you haven't already.
(In reply to V Stuart Foote from comment #11) > Default handling (scale to margins) of the pdfium generated image has > changed, but not sure that is a bug. IIU?C all images are scaled to margins > on insertion. I'd consider that a bug, if the image is smaller than that, why should it get scaled?
@Aron Budea > Yes, please open a separate bug report if you haven't already. Waiting until this major issue is solved, since behavior may get modified again in the solution. For the time being I just wanted to annotate the information on the tracker. > pdfium generated image has changed, but not sure that is a bug Unfortunately, the migration to pdfium has not been smooth. There were a lot of issues (appearance of a solid white background in imported images when the original PDF does not have it remains my main grievance). Indeed in some cases there were also behaviors that changed with no expectation that are not really bugs even if the lack of anticipation created problems. In this specific case, I would say that we are most certainly facing a bug, though. The image gets distorted for no reason, it is hart-to-impossible to fix it by editing the document and document exchange with people using other LibO versions is hindered. In any case, it is surely an easy to work around problem since other image formats exist and it is not difficult to convert PDF to something else but I am not sure this is actually a good thing. What can be expected is that users who got bitten by these issues will start working around them by editing their documents to use PNGs rather than vector images and the casual user will be told to merely avoid the LibO+PDF images combination by the more experienced one.
This seems to have been fixed in LO 7.4 by author Tomaž Vajngerl on 2021-12-06 12:43:00 +0100 commit 4c00e8fb10437fcaefe8635ef390b78376938d15 Add image preferred DPI document setting, use it in Writer, Impress This adds a "image preferred DPI" document setting, which is used as a suggestion of the DPI that an image should have in the document. This is currently used when the image is inserted into the document (Writer, Impress/Draw) to resize it to the preferred DPI value.