I tend to use FT_New_Memory_Face() on Windows, having first found
the font data using native OS API calls and then loading the font
data into memory from there...
Thanks for that tip! That is one solution. Still, it seems preferable
not to have to load the whole font into RAM. Some fonts are huge and
memory may be limited; plus there's the problem with TTC fonts. Also,
some Freetype users are likely to go on using FT_New_Face on Win32,
and not realize that it may fail on non-ASCII filenames.
How about making FT_New_Face more usable on Win32, always supporting
UTF-8 as well as the default encoding. This could go in ftstdlib.h:
#if defined(WIN32) && defined(UNICODE)
FILE * ft_fopen_win32(char *fname, char *mode);
#define ft_fopen ft_fopen_win32
#else
#define ft_fopen fopen
#endif
(Currently ftstdlib.h just has "#define ft_fopen fopen".)
The following could go wherever it belongs (maybe ftsystem.c?):
#if defined(WIN32) && defined(UNICODE)
FILE * ft_fopen_win32(char *fname, char *mode)
{
// First try fopen, assuming nothing about character encodings.
FILE *file = fopen(fname, mode);
if (file == NULL) {
/* fopen failed. Assume the filename is UTF-8, convert to UTF-16,
and try _wfopen.
These max sizes are somewhat arbitrary; could use dynamic
allocation instead,
and call MultiByteToWideChar(..., 0) to get size needed... */
#define MAX_WIN32_FNAME 2048
#define MAX_FOPEN_MODE 100
TCHAR fnameW[MAX_WIN32_FNAME], modeW[MAX_FOPEN_MODE];
if (MultiByteToWideChar(CP_UTF8, 0, fname, strlen(fname),
fnameW, MAX_WIN32_FNAME) == 0) {
return NULL;
}
if (MultiByteToWideChar(CP_UTF8, 0, mode, strlen(mode),
modeW, MAX_FOPEN_MODE) == 0) {
return NULL;
}
file = _wfopen(fnameW, modeW);
}
return file;
} /* ft_fopen_win32 */
#endif
I haven't been able to test this yet. Maybe someone will want to.
Tom
文林 Wenlin Institute, Inc. Software for Learning Chinese
E-mail: ***@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯