After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 524214 - F-Spot assumes all Exif tags to be ANSI or UTF8 encoded
F-Spot assumes all Exif tags to be ANSI or UTF8 encoded
Status: RESOLVED OBSOLETE
Product: f-spot
Classification: Other
Component: Metadata
SVN
Other Linux
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks: 524077
 
 
Reported: 2008-03-24 22:07 UTC by Debajyoti Bera
Modified: 2008-04-22 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
PATCH to use correct encoding (2.83 KB, patch)
2008-04-01 12:47 UTC, Debajyoti Bera
needs-work Details | Review

Description Debajyoti Bera 2008-03-24 22:07:26 UTC
Exif.cs: ExifEntry.Value uses a hybrid encoding approach.
It either does (for libexif 0.5)
  return Marshal.PtrToStringAnsi (exif_entry_get_value (this.Handle));
or (for libexif 0.6)
  return System.Text.Encoding.UTF8.GetString (value, 0, len);

I am not sure why it is done this way. It becomes even worse when exif tags specify their encoding to be either ASCII or UTF8 or JIS e.g. Exif.UserComment as mentioned in pg-41 of http://www.exif.org/Exif2-1.PDF specifies the encoding to use:

"The character code used in the UserComment tag is identified based on an ID code in a fixed 8-byte area at the start
of the tag data area. The unused portion of the area is padded with NULL ("00.H"). ID codes are assigned by means
of registration. The designation method and references for each character code are given in Table 6 . The value of
Count N is determined based on the 8 bytes in the character code area and the number of bytes in the user comment
part. Since the TYPE is not ASCII, NULL termination is not necessary (see Fig. 9)."
Comment 1 Debajyoti Bera 2008-04-01 12:47:48 UTC
Created attachment 108411 [details] [review]
PATCH to use correct encoding

Tested in http://bugzilla.gnome.org/show_bug.cgi?id=524077
Comment 2 Stephane Delcroix 2008-04-11 15:32:19 UTC
fixed in r3819
Comment 3 Stephane Delcroix 2008-04-11 15:41:18 UTC
reverted, doesn't compile

I guess this patch is against the Exif.cs in beagle ?

can you provide a working (against f-spot) patch, maybe with JIS support too (instead of the FIXME) ?
Comment 4 Larry Ewing 2008-04-11 16:58:57 UTC
I'm pretty sure we use the Tiff.cs version of the exif metadata for all the important uses of the UserComment field, and if you look at it you can see it handles things as gracefully as possible.  I would rather remove all use of libexif in f-spot (and beagle) that continue to work around its flaws.
Comment 5 Debajyoti Bera 2008-04-11 17:06:08 UTC
Tiff.cs:USerComment indeed looks very robust. Dumping libexif has been suggested in the past but sadly never happened. Once earlier I even tried to create a drop-in replacement of libexif by Tiff.cs in the beagle code but could not manage it :(
Comment 6 Debajyoti Bera 2008-04-20 21:31:31 UTC
I moved Beagle from libexif to the managed Tiff parser. Since then I have lost active interest in this one :P. If F-Spot does not use this internally then I have no problems marking this OBSOLETE.

I can still create a patch against F-Spot source if needed. Let me know what is your preference. Thanks.