Bug 155270 - Tags with non-Latin characters dropped during image export
Summary: Tags with non-Latin characters dropped during image export
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-WebService-Flickr (show other bugs)
Version: 5.6.0
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-08 12:10 UTC by x3ri7yz02
Modified: 2018-03-23 12:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 0.1.0


Attachments
patch for unicode tags (1.54 KB, patch)
2008-05-08 03:28 UTC, HJ D Lee
Details
new FlickrExport dialog (32.00 KB, image/png)
2008-05-21 16:10 UTC, caulier.gilles
Details

Note You need to log in before you can comment on or make changes to this bug.
Description x3ri7yz02 2008-01-08 12:10:29 UTC
Version:            (using KDE KDE 3.5.8)
Installed from:    Debian testing/unstable Packages
OS:                Linux

When exporting images with non-latin tags (specifically in my case - Korean characters), such tags are silently dropped and do not appear on Flickr.  As such tags can be added directly via the Flickr interface, I suspect the flickrexporter is discarding them?

A similar issue to bug 147268 (but that bug is for the galleryexport plugin).
Comment 1 HJ D Lee 2008-05-08 03:28:56 UTC
Created attachment 24665 [details]
patch for unicode tags

Before this patch, (Korean) unicode characters sent as '?' characters.

I changed .ascii() call to .utf8() call in MPForm::addPair() and
FlickrTalker::getApiSig()

I convert QCString to QString before sending to QTextStream.

(My guess - QCString has no encoding information.
 Without this, double converted string resulted.)

I have no previous qt library experience before this patch.

So I think QString-QCString-QString conversion may be redundant, but no try to
fix.
Comment 2 caulier.gilles 2008-05-21 11:06:23 UTC
SVN commit 810651 by cgilles:

kipi-plugins from KDE3 branch : FlickrExport tool : UTF-8 support
- Use KURL to host addPhoto url
- new method to compute MD5 signature based on KURL.

I have tested to upload photo using accentuate char from Tags or comments. Now all work fine.

BUGS: 153758
CCBUGS: 155270


 M  +41 -23    flickrtalker.cpp  
 M  +3 -0      flickrtalker.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=810651
Comment 3 caulier.gilles 2008-05-21 11:09:41 UTC
HJ D Lee, 

I have fixed in current implementation from svn severals problems relevant of UTF-8 support. 

I'm not 100% sure if this commit fix your report. 

Can you test on your computer ?

Thanks in advance

Gilles Caulier
Comment 4 x3ri7yz02 2008-05-21 15:59:36 UTC
Hi Gilles,

Thanks for your efforts!  

I have done some tests with SVN version (v0.9.4-beta5, installed today 2008-05-21 after your revisions above).  I cannot speak for HJ D Lee, but the problem does not appear to be resolved from here.

I tested three cases: (A) with a Korean tag in the image metadata only;  (B) with Digikam specifying tags during upload (application tags); and (C) with a Korean tag specified manually (in the Export to Flickr -> "Added Tags" dialog.)

(Case A):  image is tagged with a Korean tag, but the "Use Host Application Tags" checkbox is UNTICKED (so that Flickr reads metadata only from embedded IPTC tags.)  In this case, image upload is successful, and tag is partially preserved during upload to Flickr, but the Korean characters are rendered as question marks ("???").  This is an improvement (as they were dropped entirely before I think) but not very useful really.

(Case B): In this case, image is tagged with a Korean tag, and the option to "Use Host Application tags" is TICKED.  In this case, upload to Flickr fails with the following message:

     "Error Occured: Invalid signature
      We can not proceed further"

Removing the Korean tags allows a successful upload, suggesting that the tag was responsible for the error.

(Case C):  Image is NOT tagged with a Korean tag, but one is added manually to the upload dialog as above.  In this case, image uploading fails with the error message as in Case B.  As in Case B, removing the Korean tag allows image upload to proceed.

I hope this helps - please let me know if you would like further information, test images or further testing.

Thanks again for such a fantastic piece of software!

cheers,
tauri
Comment 5 caulier.gilles 2008-05-21 16:10:26 UTC
Created attachment 24872 [details]
new FlickrExport dialog

Tauri,

FlickrExport tool is a kipi-plugin. You need to checkout/compile/install
extragear/libs from KDE3 branch to test.

Warning: there are shared libs here used by digiKam. you need to recompile and
install digiKam too...

Dialog layout have been rewritten. Look screenshot attached...

Gilles
Comment 6 x3ri7yz02 2008-05-22 00:37:27 UTC
Hi Gilles, 

Yes, I can see the new dialog layout when testing. (Looks great!)  

I am using Arnd's three scripts to get the SVN version - which appear to include the extragear/kde3/libs.  As this also re-compiles Digikam, I guess it would include all the changes you made yesterday?

Please let me know if testing with Arnd's scripts is insufficient.

tauri

Comment 7 caulier.gilles 2008-05-22 11:01:36 UTC
SVN commit 811090 by cgilles:

apply MPForm class utf-8 support patch from HJ D Lee.

Work for me. indeep tests are require especially with asian/greek/arab/etc... charsets.

CCBUGS: 155270



 M  +0 -1      flickrtalker.cpp  
 M  +2 -2      mpform.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=811090
Comment 8 caulier.gilles 2008-05-22 11:02:45 UTC
Tauri,

Please checkout svn and try again following my last commit #811090.

Thanks in advance

Gilles Caulier
Comment 9 x3ri7yz02 2008-05-22 16:56:22 UTC
Hi Gilles,

Partial success!  From the use cases above (A, B and C):

Case A:  Doesn't work.  If "Use application tags" is NOT selected, Flickr only gets the tags from the IPTC data.  These are rendered incorrectly, and show up as "????" type tags on Flickr.

(But I note your comment in Digikam that IPTC can only use printable ASCII character set - so I guess this problem is a result of IPTC limitations and is not fixable via Digikam?)  

Case B:  Works.  Application tags are preserved and passed to Flickr correctly.   (Note - if the Digikam tags are stored in the IPTC data, these are also read by Flickr - and because these tags are not parsed correctly as per Case A above, images uploaded this way end up with the incorrect "???" tags as well as the correct tags.)

Case C: Works perfectly.  Korean tags entered manually in input line are preserved and passed to Flickr correctly. (And because these tags aren't in the IPTC, there are no incorrect tags.)


So - given that non-ASCII IPTC tags will be rendered incorrectly on Flickr, perhaps there could be an option to  strip them out (perhaps related to http://bugs.kde.org/show_bug.cgi?id=153207 )?  Or a warning for users?  Or some other idea?

Anyway - great work!  

tauri
Comment 10 caulier.gilles 2008-05-22 21:59:58 UTC
Tauri,

Case A: If "Use application tags" is NOT selected, Flickr only gets the tags from the IPTC data => same problem than B. Note you can enter manually tags in text edit widget, and in this case, all is fine.

Case B: => Note - if the Digikam tags are stored in the IPTC data, these are also read by Flickr => there is already a file in B.K.O about this problem.

Case C: fine.

So, i resume : all work fine for me, independently that the IPTC keywords get by Flickr. This is another issue. to fix. We will fix this problem into file :

http://bugs.kde.org/show_bug.cgi?id=153207

I close this entry now. we continue in #153207

Gilles Caulier
Comment 11 x3ri7yz02 2008-05-27 03:25:51 UTC
Re-tested use cases A,B and C after fix to #153207 - all now work correctly.

Cool!