[AD] Allegro unable to deal with non ascii filenames

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


The problem is packf_open, using uconvert_toascii() (at least under
unix). That's basically making anybody unable to use anything
other than ASCII in filenames in the 4.2.0 branch. On 4.0.0 you
could still load them if you used set_uformat(U_ASCII), patch from
http://sourceforge.net/mailarchive/message.php?msg_id=12915870
(or revision 5416) "broke" it. Note that pack_fopen was broken in
4.0.0 anyway, so it doesn't really matter, unless we want to keep
backwards bug compatibility ala windows.

I'm attaching a test case. Tweak the set_uformat to whatever you
like, but you won't be able to load filenames with 8-bit characters
under linux in a non-utf8 environment (I'm latin1). I run it in
a directory where planet.pcx is located with another hardlinked
version named planet1ñño.pcx. The latter cannot be loaded (open
always returns -1 due to filename string conversion).

Couldn't find much useful stuff from Google. All unicode faqs/howtos
center on the memory string and display issues, nobody wants
to address filesystem IO.  The only things I found closest where
http://mail.gnome.org/archives/gtk-app-devel-list/2005-January/msg00296.html
and Python's documentation, where it implements
sys.getfilesystemencoding(). I also remember setting
G_BROKEN_FILENAMES="latin1" a while back in order to make GTK
applications work.

AFAICS the problem with POSIX is that filesystem names are 8-bit
thingies, and you deal with it. The above links show that people
tend to deal with it setting environment variables or configuration
settings.

And I guess that's the only thing that we can do too, adding
al_(set|get)_filesystem_encoding, defining some environment variable
(piggybacking on G_BROKEN_FILENAMES for convenience), allowing a
configuration file setting, and making IO functions convert to/from
this specific global variable.  Everything but the new API function
could be done for 4.2.2. The new function should go in 4.3.x.

This should all be nicer on Windows, I read several times they have
some unicode aware open/fopen like calls.

PD: The maillist advanced search at SF is quite nice now.

PD2: I really hope I making a stupid mistake in the test case,
     I don't want to fix this mess.
// -*- mode:C++; tab-width: 4 -*-
#include <assert.h>
#include <allegro.h>
#include <stdio.h>
#include <string.h>

void load_file(const char *filename)
{
    PALETTE pal;
    BITMAP *bmp = load_pcx(filename, pal);
    if (bmp) {
        printf("\tLoaded %s for %dx%d\n", filename, bmp->w, bmp->h);
        destroy_bitmap(bmp);
    }
    else {
        printf("Couldn't load `%s'!\n", filename);
        printf("Errno is %s\n", strerror(errno));
    }
}

int main(void)
{
    set_uformat(U_ASCII); /* Works for 4.0.x, not for 4.2.0. */
    allegro_init();
    set_color_depth(32);
    /* Set a graphic mode to avoid assers in debug builds... */
    set_gfx_mode(GFX_SAFE, 320, 200, 0, 0);

    struct al_ffblk info;
    
    if (al_findfirst("*.pcx", &info, FA_ALL) != 0) {
        /* Tell user there are no PCX files. */
        printf("No files?\n");
        return 1;
    }
    
    do {
        /* Do something useful here with info.name. */
        printf("Loading `%s'\n", info.name);
        load_file(info.name);
    } while (al_findnext(&info) == 0);
    
    al_findclose(&info);

    return 0;
}
END_OF_MAIN()



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/