Re: [Freetype] Internationalization question

[David Turner]

Hi Jeff,

> 
> Hello,
> 
> I wanted to find out if there are any known issues with using the freetype2
> library on OSes with international language support.  For instance, Japanese
> Solaris or WinNT?
> 
> If I have a font file in a directory path which includes multibyte characters,
> will calls to FT_New_Face() handle the path string?  Does the string need to 
> be
> in UTF-8 format or what is best there?  Are there differences that I need to 
> be
> aware of between WinNT and Unix specifically relating to freetype2?
> 
> Let me know if I need to be more specific.
> 

I don't think you'll need to :-) There are basically two ways to
support your platform:

  - create a custom FT_Stream and use it to create a new face object
    with FT_Open_Face (instead of FT_New_Face). This have the advantage
    of working with FT2 "out-of-the-box"

  - otherwise, the default implementation of streams is implemented by
    the file "src/base/ftsystem.c". However, certain builds can also
    provide an alternative implementation. As an example, the Unix build
    does use the file "builds/unix/ftsystem.c" instead.

    You could thus create your own version of "ftsystem.c", especially
    with your own implementation of FT_New_Stream. This function is in
    charge of creating a new stream object from the file pathname passed
    to it by FT_New_Face (the rest of the library never uses the file pathname
    so it can point to any kind of data)

    The FT2 command line build system uses the environment variable FTSYS_SRC
    to hold the absolute path to the "ftsystem.c" implementation.

In all cases, you'll need to read <freetype/ftsystem.h> for the definition
of FT_Stream objects, and probably "src/base/ftsystem.c" and 
"builds/unix/ftsystem.c"
to see how to implement them. It's not really hard by the way :-)

There are no NT/Unix specific in the library itself, it entirely relies on
an ANSI C library, and doesn't use locales or other broken (relative to
portability) i18n stuff..

The strings returned by the library are extracted from the font files themselves
and are most probably ASCII or Latin-1. Note that TrueType and OpenType fonts
can also contain internationalised strings, but that's a format-specific issue,
not a platform-specific one..

Regards,

- David