If I insert a PNG file as an OLE object, I don't see the PNG image. Instead, I see an empty rectangle; when I double-click it, it seems an embedded Draw instance is working - with a full page, at the center of which is the PNG image. Both the aspects of these behavior seem inappropriate to me - but especially the fact that the image is not seen in the document. Behavior is the same/similar in both Writer and Draw. Using: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c8371b5f1a84191d38185820915f0d93741df1fe CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_IL); UI: en-US
I wonder if it's just a bug, or intentional somehow.
STR: * Insert > OLE Object > OLE Object... * Pick some raster graphic => the object is empty or cut off at some point depending on the image dimension
I am not sure if it is a bug. An OLE object is managed through another program that manages the file, in this case it is the same Draw, but it is another instance. Editing allows to correctly position the image, inside the OLE window. This is necessary because by default the image is positioned in the center of the page. Insert as image (linked or not) works fine.
The frame of the newly inserted OLE does not seem to parse the dimensions of the source image. The frame is centered on draw canvas but is too small to hold what arrives as OLE. So for just some images seems empty. So behavior is not wrong--it just creates the OLE with some default frame size (not drawn from the incoming OLE), and user is expected to resize the OLE image in any case. But, it would be helpful if either of two things could happen: 1.) allow the OLE to be parsed by its LO filter, and then set the frame size to match incoming OLE 2.) adjust the defaults for OLE frame(s) to extend to a greater percentage of document canvas (but not overlay the margins to be able to select). Matching the incoming OLE, then scaling would combine both. But just doing the second is probably more performant and easier to implement.
(In reply to m_a_riosv from comment #3) To clarify - if it's not a bug, then it's a mis-design. First, it's not at all obvious that Draw should manage/handle/edit a PNG image; it's not a raster image editor after all. But even granting that the choice of Draw is legitimate - the end result needs to be that we see the PNG image in the document into which we inserted it, after the insertion.
I'll compromise on the severity, but the current behavior is not appropriate, even if it is not the result of an implementation error.