Qt does not seem to be able to load the apropriate glyph when Thai text, for instance, is mixed with English text.
Steps to reproduce:
1. create a directory, say /tmp/fonts and place DroidSans.ttf and DroidSansThai.ttf there
2. Use an alternative fontconfig config file (fonts.conf - see attached file) that points to this directory
3. Export FONTCONFIG_FILE=/path/to/alternative/fonts.conf
4. Run the attached program
5. Paste the following Thai text: สวัส
6. Insert a dot character in between the text: ส.วัส for instance
The dot character will be rendered as a square.
So far (I had never looked into QFont* classes source code before) what I could find out is that apparently (take this with a grain of salt) the whole piece of text is treated as Thai script (21). Because DroidSansThai.ttf does not contain the glyph for the dot, it will try to find a fallback family, which in this case DroidSans.ttf is the only available fallback font.
It then loads it (or reloads it?) but when QFontDatabse tries to perform a match, even though the family name string matches, the writing system match fails (because DroidSans.ttf does not support the writing system 21 - Thai).
Since there are no more fallback families to be tested, and consequently loaded, a null glyph is returned and a square is rendered.
If the following code is commented out from QFontDatabse's static int match() function, then it works:
if (script != QChar::Script_Common && !(test.family->writingSystems[writingSystem] & QtFontFamily::Supported))
I know this is just an ugly hack and not the way to go, but once you ignore the writing system check, DroidSans.ttf passes the match test and the appropriate glyph is loaded.
Also, please note that if a space is inserted after the Thai text and then the dot is typped, it appears normally.
The attached file contains all the necessary files.