An existing .odg drawingis being edited. With nothing selected, [Insert]->[Image...] dialog box is used, and a .GIF file is selected. Upon [ Open ], an image is added to the drawing, but it is NOT the image chosen - it is another image already inserted into the drawing. The previously inserted image is a .JPG (if that has any bearing on the problem.)
After [Edit]->[Undo Insert ...], I used GIMP to read the .GIF file, [Export] it as a .JPG, and re-do the [Insert]->[Image...] -- selecting the just created .JPG. This time the expected image is inserted.
Steps to Reproduce:
0. Existing drawing with several images placed; drawing opened
for editing. Have a .GIF image in a file ready to be the
target of an [Insert]->[Image...]. Nothing selected
1. Open file selection dialog box using [Insert]->[Image...], select
your .GIF image
2. hit [ Open ]
3. A previously-used image is re-instantiated into the drawing, NOT
the image in the selected .GIF
An additional placement of an image already in the drawing newly appears, and the image in the selected file is nowhere to be seen
Image in the .GIF file should be placed on the drawing canvas, ready to be resized, moved, etc.
User Profile Reset: No
[Information automatically included from LibreOffice]
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Build ID: 188.8.131.52-1.fc26
CPU Threads: 8; OS Version: Linux 4.13; UI Render: default; VCL: gtk3; Layout Engine: new;
Locale: en-US (en_US.UTF-8); Calc: group
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36
Please attach an example document.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Created attachment 137908 [details]
Example reproducer (.tgz)
Attached file - Bugz-113962-Example.tgz - contains an .odg and 2 image files: one .jpg, another .gif
1. make a new empty directory && cd there
2. extract: tar -xvf Bugz-113962-Example.tgz
3. open NetDiag.odg
4. Do [Insert]->[Image...] && select the file Fconnector-RG-6-ActuallyJPG.gif
5. Do [ Open ]
NOTE: The problem [Insert]->[Image...] occurs with the file
As the current file name implies the actual content of the file is in .JPG format, but the "name" of the file is using the .gif extention. Don't know origin of that confusion; it was downloaded from a Google images search that way (then renamed as you see here, but keeping the .gif extension).
Image appearing on the drawing canvas is the already-present picture of a
D-Link desktop 8-port switch
1.) Image appearing on the drawing canvas is the image actually in the file -
that of an RG-6 F-connector
-- or --
2.) An error message that the file actual content (.JPG) is not of the
type implied by the file name suffix (.gif)
NOTE: Even though there is a disagreement between the file name suffix
(".gif") and the actual content type (".jpg", as shown with the "file"
shell command), other image viewers - including 'GIMP', the Midori, Opera, Firefox and Chrome browsers - pick up and render the file as per actual
NOTE: I find that the 'Ristretto Image Viewer' does notice the
disparity and shows a blank image and a top banner error message.
Ah, very cool... this is a GTK3-only issue! VCL backends kde4 and gen work fine.
Other weirdness: with GTK2, it says "Image filter not found".
It is truly dependent on the wrong file extension. GTK3 works fine, if I rename the file to .jpg.
Arch Linux 64-bit
Build ID: 1d9eed341db208f11de6f020538dfdb74a5c48dd
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on November 22nd 2017
well, gtk2 also I Imagine as well as gtk3. Looks like the gif is detected as a jpg, that filter set on the dialog as the current filter as a place to stash the detection of the true type and the generic file dialog will return that, while the gtk file picker will refetch the type based on the filename.
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":
Resolves: tdf#113962 save detected filter outside file dialog
It will be available in 6.0.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.