#17 Unicode bugs / Visual Studio
A lot of Unicode reported bugs in FTGL are due to Visual Studio UTF-8/UTF-16 encoding (eg. div bugs in FTCharToGlyphIndexMap.h and Indices[] overstepping bounds). The FTUnicodeStringItr iterator in FTUnicodeStringItr.h uses templates, and treats UTF-16 encoded characters as UTF-8, all due to Visual Studio compiler issues (tested with VS2008). Fixing the encoding of all source files corrects the problem.
May I suggest that someone with write access inserts a big warning / comment about this issue. The easist way to identify that this is the problem which people are encountering is to temporarily modify the operator FTUnicodeStringItr& operator++() so that the UTF-8 case executes the UTF-16 code path instead. If their code stops crashing / starts working, then they know that they have run into a Visual Studio related issue.
It will save countless Unicode/FTGL crashes reports.
Are you implying that Visual Studio will compile differently depending on the source file's encoding? Do you know what exactly changes with the encoding? Any links about the issue would be appreciated.
I know nothing about unicode encoding, but I can confirm what the original poster is saying.
I'm working with basic 8-bit char types. In FTFontImpl::BBoxI when it converts the string to a FTUnicodeStringItr, then into two unsigned ints, everything works until you get to character code 192.
The thisChar becomes 4294967168 and nextChar is 844.
Character 193 becomes 4294967232 with nextChar becoming 844.
The suggestion to use readUTF16 instead fixes the issue.
I'm compiling with VS2005, I tried compiling FTGL with both multibyte and ascii character sets, without any difference.
Oh, I will point out I'm using the 'official' released version from 2008, not the latest SVN version.
So is the workaround for this to change:
switch (sizeof(T))
{
case 1: // UTF-8
// get this character
readUTF8(); break;
case 2: // UTF-16
readUTF16(); break;
case 4: // UTF-32
// fall through
default: // error condition really, but give it a shot anyway
curChar = *nextPos++;
}
so that case 1 executes readUTF16() (for vs2005 and vs2008)?
Does anyone know if the same problem is present in vs2010?