Bug 272180 - Camera Device Summary seems to use wrong encoding
Summary: Camera Device Summary seems to use wrong encoding
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: Import-Gphoto2 (show other bugs)
Version: 2.0.0
Platform: Gentoo Packages Linux
: NOR minor (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-01 19:43 UTC by Thomas Eschenbacher
Modified: 2017-08-16 06:14 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Eschenbacher 2011-05-01 19:43:54 UTC
Version:           2.0.0 (using KDE 4.6.2) 
OS:                Linux



Reproducible: Always

Steps to Reproduce:
* enter the "import from camera" dialog
* show the camera info through "Device" / "Information"
* select "Summary" and look at the text on the right side

Actual Results:  
The german "umlaut" characters are not shown. Example:
"Fähigkeiten des Geräts:"


Expected Results:  
should be:
"Fähigkeiten des Geräts:"

Looks like either an i18n error or some QString::(to|from)(Local8Bit|Utf8) or similar is missing when setting the text box on the right side.
Comment 1 caulier.gilles 2011-05-01 20:07:19 UTC
Yes, i remember to have seen something similar with my old Minolta camera, through Gphoto2 PTP driver.

These string come from Gphoto2. Something is wrong in this library.

Gilles Caulier
Comment 2 Thomas Eschenbacher 2011-05-29 07:20:09 UTC
Ok, I wouldn't go so far to say that there is something wrong in that library. The question rather is "which string encoding does their API offer?"

I did a quick look at the libgphoto2 sources, but I did not see any note about a concrete "encoding". It seems that they use just "char*" and the strings contain "translated text" (at least the comments in the code says so). 

That means for digikam, that whenever receives such a string from the library, it probably needs to be converted it by using QString::fromLocal8Bit(), fromUtf8() or similar. 

My system here is configured to use UTF-8 as native encoding, so I guess that fromLocal8Bit(...) might be a good choice. Could you please give this a try?

Thomas
Comment 3 caulier.gilles 2011-06-06 13:35:48 UTC
Thomas,

If you use git master source code, the function from digiKam Gphoto2 interface relevant of this problem is there :

https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/utilities/cameragui/devices/gpcamera.cpp#L1365

Feel free to test and provide a patch if you find the right solution...

Thanks in advance

Gilles Caulier
Comment 4 Marcel Wiesweg 2011-06-11 17:08:41 UTC
I'm sure Marcus can enlighten us whether to use fromLocal8Bit() instead of fromAscii() for the text from gp_camera_get_summary...
Comment 5 Marcus Meissner 2011-06-11 17:51:07 UTC
libgphoto2 uses bindtextdomain() when initializing abilities, so it uses
the system locale and encoding.

So for LANG=de_DE.utf8 it will get UTF-8.

not sure which exact QT function this expresses, but I would also like to
know as kcmshell4 kamera has the same problem.
Comment 6 Marcel Wiesweg 2011-06-11 22:45:18 UTC
Thanks Marcus. QString::fromLocal8Bit() should be using the current locale settings.
Comment 7 Marcel Wiesweg 2011-06-11 22:53:35 UTC
Git commit e0123e4ba0f7848ea85f2e84e2dcfe4fd8aa17ec by Marcel Wiesweg.
Committed on 11/06/2011 at 22:52.
Pushed by mwiesweg into branch 'master'.

Use fromLocal8Bit to convert gphoto2's strings to QString

BUG: 272180

M  +2    -1    NEWS     
M  +4    -4    utilities/cameragui/devices/gpcamera.cpp     

http://commits.kde.org/digikam/e0123e4ba0f7848ea85f2e84e2dcfe4fd8aa17ec
Comment 8 Marcel Wiesweg 2011-06-11 22:58:34 UTC
untested, no device, but it really should work.
Comment 9 Thomas Eschenbacher 2011-06-12 08:54:43 UTC
I applied this patch to my local copy of digikam-2.0.0_beta5 and can confirm that it works fine now, all strings are shown in the right encoding (which is UTF-8 in my case).

thanks for fixing,
   Thomas.