Archived issue #0030970
Visualization - Font Name don't support Unicode (such as Chinese)
Description
void Font_FontMgr::GetAvailableFontsNames(TColStd_SequenceOfHAsciiString& theFontsNames) const;
The font names from above method is not readable for Unicode font name such as Chinese.
The font names from above method is not readable for Unicode font name such as Chinese.
Public activity
5 archived notes
Participants are labeled by their role within this record.
Please provide some steps to reproduce / test data / output.
pload VISUALIZATION #vfont -add pathToSomeFont.ttf vfont
uploaded a font file Attachment 1 (TTF)
This is not an OCCT bug, but FreeType limitation.
FreeType documentation states, that it relies solely on fopen() for being portable, without any wfopen() alternatives on Windows in any way (via dedicated API or via fallback for UTF-8 names).
For instance, FreeImage duplicates all file-related APIs with wchar_t variants for handling WinAPI UNICODE issue (FreeImage_GetFileTypeU+FreeImage_GetFileType, FreeImage_LoadU+FreeImage_Load, etc.),
FFmpeg follows "utf-8 everywhere" conception, similar to OCCT, so that it expects file names given in UTF-8 and calls wfopen() implicitly on Windows.
FreeType is currently different.
Alternatives:
- Rename font file.
Obviously, can be done only if font comes with application.
- Using short DOS names as fallback.
Side effect: this obsolete file system feature can be disabled on modern Windows systems.
- Pre-loading entire file in memory and using FT_New_Memory_Face() instead of FT_New_Face().
Side effect: entire file has to be loaded into memory.
- Using FT_Open_Face() instead of FT_New_Face() with custom stream wrapper.
Side effect: extra dirty mess-up and complication of OCCT code base.
I would say, pushing FreeType project in more Windows-friendly direction would be perfect solution rather than messing up in OCCT, as long, as this is not a blocking issue.
FreeType patch, which would handle UTF-8 filenames on Windows, has chances to be integrated - at least it should not contradict to project's philosophy.
FreeType documentation states, that it relies solely on fopen() for being portable, without any wfopen() alternatives on Windows in any way (via dedicated API or via fallback for UTF-8 names).
For instance, FreeImage duplicates all file-related APIs with wchar_t variants for handling WinAPI UNICODE issue (FreeImage_GetFileTypeU+FreeImage_GetFileType, FreeImage_LoadU+FreeImage_Load, etc.),
FFmpeg follows "utf-8 everywhere" conception, similar to OCCT, so that it expects file names given in UTF-8 and calls wfopen() implicitly on Windows.
FreeType is currently different.
Alternatives:
- Rename font file.
Obviously, can be done only if font comes with application.
- Using short DOS names as fallback.
Side effect: this obsolete file system feature can be disabled on modern Windows systems.
- Pre-loading entire file in memory and using FT_New_Memory_Face() instead of FT_New_Face().
Side effect: entire file has to be loaded into memory.
- Using FT_Open_Face() instead of FT_New_Face() with custom stream wrapper.
Side effect: extra dirty mess-up and complication of OCCT code base.
I would say, pushing FreeType project in more Windows-friendly direction would be perfect solution rather than messing up in OCCT, as long, as this is not a blocking issue.
FreeType patch, which would handle UTF-8 filenames on Windows, has chances to be integrated - at least it should not contradict to project's philosophy.
It's not the font file name problem, it works well to load the font file with method CheckFont:
Handle(Font_SystemFont) Font_FontMgr::CheckFont (const Standard_CString theFontPath) const.
The problem is that the name of the font returned from CheckFont is not readable with character "??????".
The test system is android.
the file path is utf8 character.
Handle(Font_SystemFont) Font_FontMgr::CheckFont (const Standard_CString theFontPath) const.
The problem is that the name of the font returned from CheckFont is not readable with character "??????".
The test system is android.
the file path is utf8 character.
> The problem is that the name of the font returned from CheckFont
> is not readable with character "??????".
This is another problem, but still relevant to FreeType library - the name is returned from FT_Face::family_name.
> is not readable with character "??????".
This is another problem, but still relevant to FreeType library - the name is returned from FT_Face::family_name.
Related records