[Octave-bug-tracker] [bug #58493] Accentued letter (french accent) in file path problem and Magick++ exception

[Markus Mützel]

Follow-up Comment #7, bug #58493 (project octave):

For the Windows installer, we are packaging GraphicsMagick not ImageMagick.
They seem to use fopen (with char input) on all platforms.

The Windows API is a little weird when it comes to characters: There are
basically to flavors of the API.
One flavor is the ANSI API that uses char. The name is misleading because that
API really uses the locale encoding. (Well, it is "correctly" named if you are
on a machine with US locale.)
The other one is the Unicode API using wchar_t.

In this case, it doesn't really matter how file names are stored in the file
system (might as well be UTF-32 or a proprietary encoding) because the APIs
should make the access transparent.

ImageMagick seems to have chosen to expect UTF-8 at there interfaces. On
Windows, they convert these char arrays to wchar_t and use the Unicode API.

GraphicsMagick on the other hand has a more "native" interface. They don't do
any conversion and just pass the input on to the ANSI API:
http://hg.code.sf.net/p/graphicsmagick/code/file/a42b29bea408/magick/blob.c#l2862

That really is a mess.

Good thing is that we do the packaging for Windows ourselves. So we know that
we are dealing with GraphicsMagick. Otherwise, we would need to somehow detect
on run-time if we were dealing with ImageMagick or GraphicsMagick, and pass
the file names in the respective encoding.

Anyway, it looks like we are back to what I wrote in comment #3.

Maybe we could try both approaches I outlined there and only fail with a
descriptive error if both failed.

I've also seen that "imread" fails if it is given an absolute path to a file.
But that is probably a different bug.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58493>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/