search

jukkar / gpicsync

Automatically exported from code.google.com/p/gpicsync
Other
0 stars 0 forks source link

Non ASCII characters in IPTC/keyword incorrect #117

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Use photos and track from some place having Polish characters in name
2. Enable any geonames mode
3. Non-ASCII characters mangled

What is the expected output? What do you see instead?
Expected: correct characters or mapped to ASCII.
Getting: Characters from wrong codepage

What version of the product are you using? On what operating system?
1.29 on Win7 x64 (PL)

Please provide any additional information below.

Original issue reported on code.google.com by mszok...@gmail.com on 4 Aug 2012 at 11:33

GoogleCodeExporter commented 8 years ago 
May be related: In version 1.29 if I enable geonames, frequently the tagging 
will stop after few (3-5) pictures and simply ignore the rest of folder.
Without names (only coords) works fine.

Original comment by mszok...@gmail.com on 4 Aug 2012 at 11:35

GoogleCodeExporter commented 8 years ago 
Thank you for your feedback, I just gave it a try with a set containing non 
ascii characters (French/German) and you’re right it stops geocoding.

It should still work from previous versions (it does for my set). Could you try 
with version 1.28 with your Polish dataset and tell me if it works for you?
http://sourceforge.net/projects/gpicsync/files/GPicSync/GPicSync1-28/GPicSync1-2
8.exe/download

The problem comes since I’ve updated to unicode to support all languages like 
it should be ideally. Apparently there’s a problem with Python 2.x when I 
call  through a DOS command (the geocoding library exiftoo.exe here). More 
infos on this here:
http://code.google.com/p/gpicsync/source/detail?r=950 

Apparently it would work if I rewrite the application for Python 3.x but two 
important libs I use are not ported yet (WxPython the GUI and Python Imaging 
Library). Really annoying since I don’t intend to make big tech changes on 
this application since I don’t geocode often now :/

I will see if I can find a work around even if it doesn’t cover all languages 
it should be better than just ascii. If you can send me a test sample with two 
pics and a gpx (just for testing purposes) it could be helpful too.

Thanks for your feedback.

Original comment by francois...@gmail.com on 5 Aug 2012 at 5:57

GoogleCodeExporter commented 8 years ago 
This is for now a partial solution given the unicode constraints mentioned 
above:
https://dl.dropbox.com/u/113646/GPicSync1-30.exe

Geonames are unicode within GPicSync but when it needs to send the Geonames 
through the command-line (to exiftool) it will translate them at best in ascii 
(taken out accents for example)using this lib: 
http://pypi.python.org/pypi/Unidecode/

I will check the python3 availability of WxPython and PIL from time to time and 
probably update gpicsync to python3 when it will be available.

Original comment by francois...@gmail.com on 6 Aug 2012 at 7:09

GoogleCodeExporter commented 8 years ago 
It doesn't stop now, but it seems Unidecode is not working correctly.

I've looked in the documentation and in the original Perl source and it should 
deal reasonably with Polish letters (haven't looked for other languages). Yet 
it turns "Śródmieście" into "rdmiecie" :-(

Original comment by mszok...@gmail.com on 29 Aug 2012 at 10:49

GoogleCodeExporter commented 8 years ago 
"""I've looked in the documentation and in the original Perl source and it 
should deal reasonably with Polish letters (haven't looked for other 
languages). Yet it turns "Śródmieście" into "rdmiecie" :-("""

Exiftool is unicode. The problem is sending through *DOS* with Python 2.x:
http://bugs.python.org/issue1759845

If Exiftool was a Python library there wouldn't be any problem (not needing to 
go through DOS).
To rewrite GPicSync in Python 3.x I need WxPython and PIL to be written in 
Python 3

I will probably scrap unicode in the next version to go back to what it was in 
version 1.28 which should work (non unicode). If I knew there was this problem 
and the two important libs not present in python 3, I would have waited.

Original comment by francois...@gmail.com on 30 Aug 2012 at 6:34

GoogleCodeExporter commented 8 years ago 
Just confirming that in 1.3 if files are in folder containing symbols, it just 
stops without any error.

ÖÄÜÕ in Estonian.

Working with 1.28 version.

Also, this program is the best working so far, thank you

Original comment by min...@gmail.com on 19 Feb 2013 at 10:01