On Tue Jul 25 10:01:53 2023 +0000, Jactry Zeng wrote:
This was probably taken from requires_fallback() in uniscribe. But I
agree, it's assuming too much, and I suspect is incorrect in uniscribe too. For example it doesn't consider that not every character has to have a glyph to produce meaningful output, control characters are one example. You are right. I wrote two programs for rendering the word "Wine" with a .ttf font which only "implemented" glyph for 'W', one uses uniscribe APIs, and the other uses richedit. (The font actually was copied from dlls/gdi32/tests/vertical.ttf.) On Windows, both uniscribe and richedit use vertical.ttf for rendering the character 'W' and use a fallback font for the rest. I think this is enough to indicate that native uniscribe and richedit does fallback character by character:  Thanks! [font_fallback_tests.zip](/uploads/1cb1c10015eca367b4c17a2a09b9ffaf/font_fallback_tests.zip)
So wouldn't that imply that the fix should be in uniscribe and not richedit?