Description: I'm delighted to see that I can now drag & drop a PDF into a Writer document, and even more that exporting the document retains the selectable text of the embedded PDF. That's simply amazing. A relatively tiny issue I've noticed is that the Writer seems to be convinced that the object representing the PDF is a PNG image, which is not really the case, and it misrepresents what the exported PDF might look like (I would not expect a selectable text when it is reported as PNG image). Steps to Reproduce: 1. Drag & drop a PDF file into a Writer document 2. Right click > Properties > Rotation Actual Results: The PDF file is described as image Expected Results: I would expect it to be described as a PDF Reproducible: Always User Profile Reset: No Additional Info: Nothing else
Created attachment 203795 [details] PDF embed being described as an PNG image
That's actually normal. When a PDF file is copied or pasted into Writer, it is inserted as an embeded object(image). If you want to edit the PDF content, open it in LibreOffice Draw instead.
I don't want to edit it, which is why I did not mention anything like that anywhere in this issue. The embed is, however, quite demonstrably, not a PNG image as such. I hope you would agree that if it truly were a PNG, there would be no selectable text from the original PDF in the exported PDF, which there is.
No in fact, since the 7.2.0 release, you *are* working with a PNG representation. LibreOffice implements an insert filter that uses the Chromium project pdfium libs to convert PDF into bitmap. Insert as Vector image to a skia canvas is not yet implemented. The inserted/DnD bitmap is sized to fit document page, and responds to a system environment variable PDFIMPORT_RESOLUTION_DPI adjusted to user preference. Currently the source PDF is only parsed from the PDFs first page. So PDF must be split externally. bug 114234 remains open to implement UI to avoid need for external split. Bitmap image is held in document archive as PNG, while the source PDF is also kept. So some risk of unintended information release, bug 131768. You can just open the document's ODF zip archive file and you'll see the bitmap and the source PDF in the 'Pictures' directory.
It may very well be true that what the Writer stores it as a PNG and/or shows to me is a PNG, but at the end of the day it does not export it as a PNG, so calling it a PNG is confusing.
FWIW: I find it confusing too. In case of compress dialog thumbnail image information being shown (so including PNG file-format), while actually being based on high resolution PDF. The PDF is actually lost if you use compress. But how should someone know it's actually PDF, if filetype is shown as PNG? See bug 166930
You should also look at what happens when you use a PDF as a page background. It's referred to as a "bitmap" in some places, IIANM.
Tested on Windows 11, LibreOffice 25.8.2.2. Dragged a PDF into Writer and selected it. In the Properties sidebar the object is labeled simply as “Image” or .png, not as a PDF, which matches the observation. However, I noticed that saving and exporting to PDF preserves the selectable text from the original PDF on my system. So some of the underlying pdf data is retained.
(In reply to GJord from comment #8) > Tested on Windows 11, LibreOffice 25.8.2.2. > > Dragged a PDF into Writer and selected it. In the Properties sidebar the > object is labeled simply as “Image” or .png, not as a PDF, which matches the > observation. > > However, I noticed that saving and exporting to PDF preserves the selectable > text from the original PDF on my system. So some of the underlying pdf data > is retained. That is because only one page of the PDF is "rendered" onto the document canvas, but the source PDF (all pages) remain in the document archive available to support the export filter process that reuses the PDF page. But note that any scaling/rotation changes made to the image will simply remove the original PDF from the document (it is no longer relevant)--and only the transformed image (as a PNG) is used for the export or print. This is intentional and by design validity of layout vs. fidelity to source PDF.
(In reply to dolezvo1 from comment #5) > ...calling it a PNG is confusing. (In reply to Telesto from comment #6) > FWIW: I find it confusing too. (In reply to Eyal Rozenberg from comment #7) > ...PDF as a page background. It's referred to as a "bitmap" I see no actual use case that is broken, and you all get why the PDF is inserted as raster graphics. So why bother with a confusion? My take: WF.
While still intact in archive (until its associated BMP is transformed) the PDF is only kept for print/export handling. Its pdfium generated BMP, held as PNG, is what is being manipulated on the document canvas--any change/transform will release the original PDF and clobber it. Still much that could be done as for bug 114234 that might facilitate keeping the PDF around longer when its BMP has been manipulated. But the observation of the comment 0 "The PDF file is described as image" is exactly correct.
(In reply to Heiko Tietze from comment #10) > I see no actual use case that is broken, and you all get why the PDF is > inserted as raster graphics. So why bother with a confusion? My take: WF. Well there are some practical implications A) You insert a mix of PNG and PDF images? How do you separate both of them? Currently you need to unzip the ODT for clarity B) A PDF document retains the selectable text of the embedded PDF when exported to PDF. Not something you expect for PNG (comment 1) C) Using compress Image entails deleting the embedded PDF, but how can you be aware of it being an PDF and not a PNG, as this is the filetype identified in the Compress Dialog. Question is even if Insert -> Image being the 'proper' way. Some could argue it should actually be a separate category: Insert -> PDF. * Not a screen capture type of the PDF (image), get inserted by truly the PDF itself * The PDF can also be text-only, so not the label 'image' is not really appropriate. * The text is even selectable after PDF export of a document with embedded PDF (as under B), which is again atypical for an image. * This would make it possible to show the PDF's in the navigator as separate category, making it way easier to identify. Yes, insertion of a PDF can also be done by drag & drop and copy/paste but that's not the point..
(In reply to Heiko Tietze from comment #10) > I see no actual use case that is broken, and you all get why the PDF is > inserted as raster graphics. So why bother with a confusion? My take: WF. Well, 1. A PDF is not a PNG. If we insert a PDF, in any other way than clobber it into a PNG with the original gone forever - we can't refer to it as a PNG, that's lying to the user and is itself unacceptable. And indeed, as Stuart Stuart points out, we don't fully-clobber, we remember that it's a PDF that we might do something with. 2. When inserting a PDF, at least a choice of page to display is important to offer (if not, in fact, a choice of whether to rasterize a page or just show an opaque PDF icon). That is bug 114234. When that is implemented, we will need to tell the user which page has been rasterized, which we can't do if we claim it's just a PNG image. Plus, we don't need a complicated fix for this bug. It could just be: "Type: PDF (rasterized first page)" or "Type: Rasterized PNG image (from PDF)" or whatever.