| Summary: | Insert Image instances wrong image in drawing (.jpg with .gif extension, GTK3-only) | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | James D Howard <jhoward> |
| Component: | Draw | Assignee: | Caolán McNamara <caolan.mcnamara> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | ilmari.lauhakangas |
| Priority: | medium | ||
| Version: | 5.3.7.2 release | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | target:6.0.0 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 103182 | ||
| Attachments: | Example reproducer (.tgz) | ||
|
Description
James D Howard
2017-11-21 03:19:41 UTC
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
To reproduce:
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
Fconnector-RG-6-ActuallyJPG.gif
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).
Result:
Image appearing on the drawing canvas is the already-present picture of a
D-Link desktop 8-port switch
Expected result:
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
content.
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 Version: 6.0.0.0.alpha1+ 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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8c9a3195068bf00e00290f363d5028e9986bbba6 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback. |