Author Topic: Bugs regarding character set transcoding  (Read 2753 times)

0 Members and 1 Guest are viewing this topic.

JD?ugosz

  • New member
  • *
  • Posts: 1
    • View Profile
Bugs regarding character set transcoding
« on: 2015-05-10 19:08:22 »


Note that '?', U+03B1 GREEK SMALL LETTER ALPHA, is encoded as two bytes CE,B1 in UTF-8, and 'α' is what you get if you interpret that as Windows-1252 (English), it looks like CE,B1.

Now the plug-in might not be interpreting it the same way as the dialog box.  It's easy to miss things in error reporting, or leave problems like using -A forms of functions that are done correctly in "meaningful" code.

Checking the underlying call to CreateFile, I see both:

Thumbs9.exe   4692   CreateFile   \\OORT\Media\Images\Days\2015\05-May\?6000 camera practice\DSC00002.ARW   SUCCESS   

Thumbs9.exe   4692   CreateFile   \\OORT\Media\Images\Days\2015\05-May\α6000 camera practice\DSC00002.ARW   NAME NOT FOUND

(aside: this forum doesn't have
 formatting! )

where the first (good) one comes directly from Thumbs9.exe and the latter (bad) one comes from PolyImagePro.DLL.

So you are calling functions with UTF-8 strings when they expect so-called ANSI strings, or transcoding current-code-page-to-wide before calling -W functions, or some permutation on that.

Changing to use DCRAW plug-in instead, there are no errors reported but thumbnails are not generated.  Procmon shows otherwise:

Thumbs9.exe   4692   CreateFile   \\OORT\Media\Images\Days\2015\05-May\a6000 camera practice\DSC00002.ARW   NAME NOT FOUND   

Look carefully:  the file name has been changed from '?6000' to 'a6000'.
This call is made from PolyImagePro.DLL via plug_digicam.tpp.

Naturally, changing the file name is not a proper thing to do when loading a file!  Not reporting the error is bad on top of that.