Smilies in chat cause GetTextureForString errors
The next steam client will have some font handling improvements which should help here.
The 1/16 client is out, does this work for you?
If I paste in ‘(smilies, github doesn’t like them in comments)’ it works correctly, but the first two lines of characters from the gist still cause the problem.
First line output
First output:
surface_opengl.cpp (845) : Assertion Failed: !"Current texture not set"
surface_opengl.cpp (505) : Assertion Failed: GetTextureForString failed
surface_opengl.cpp (845) : Assertion Failed: !"Current texture not set"
surface_opengl.cpp (505) : Assertion Failed: GetTextureForString failed
Second:
surface_opengl.cpp (505) : Assertion Failed: GetTextureForString failed
surface_opengl.cpp (505) : Assertion Failed: GetTextureForString failed
surface_opengl.cpp (505) : Assertion Failed: GetTextureForString failed
The asserts suggest the font Steam is using doesn't have those characters. We shouldn't assert, but even after fixing the assert the characters will just be boxes. Can you do 'fc-match -v :family=Arial' to see what font that chooses? In the charset section there'll need to be a line for 0030 (with non-zero bits) for the first two lines and 01f6 for the smileys. If they aren't in your base font try with a family of WenQuanYi Zen Hei and see what you get. If neither has it then Steam won't be able to draw the characers (and will currently assert).
Hmm, there’s no 0030 in Arial:
002e: 00800000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00a7: ff800000 00000003 00000000 00000000 00001f00 00000000 00000000 00000000
00fb: e0000006 5f7fffff ffffffdb ffffffff ffffffff 0003ffff fff80000 f00003ff
or WenQuan (DejaVuSans):
002d: 00000000 ffff0000 ffffffff 0000803f 00000000 00000000 00000000 00000000
002e: 01000000 0000403c 00000000 00000000 00000000 00000000 00000000 00000000
004d: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff ffffffff
Full output: https://gist.github.com/4561100
I did notice from that though, that I have an updated Arial over the distro corefonts, so hmm
john@joran ~/Steam > ll /home/john/.fonts/arial.ttf /usr/share/fonts/truetype/*/Arial.ttf
-rw-rw-r-- 1 john 774476 2009-06-10 13:43 /home/john/.fonts/arial.ttf
-rw-r--r-- 1 root 275572 2000-05-11 11:45 /usr/share/fonts/truetype/msttcorefonts/Arial.ttf
Removed my ~/.fonts/ fonts and purged fc-cache,
fc-match -v :family=Arial
file: "/usr/share/fonts/truetype/liberation/LiberationSans-Regular.ttf"(s)
fc-match -v :family="WenQuanYi Zen Hei"
file: "/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf"(s)
neither have 0030
That's expected, neither Liberation Sans nor DejaVu Sans should have them. That's why Steam can't draw them and asserts. The asserts will go away in the next client, in favor of boxes. If you install WenQuanYi Zen Hei it has 30 and you'll get those, but the downside is that Steam will use that font and you'll lose your smileys (which are currently coming from DejaVu Sans) since it doesn't have those. We've been talking about how we can pick fonts to get maximal coverage but it's a mess since everybody can have different fonts.
Boxes are understandable, at least, though its going to confuse people that have that font coverage :)
Pango could be an option because of glyph fallback support, its already pulled in with libcef, thats a decent chunk of work though. The bonus there would be, I assume, universal font handling between client, overlay and browser.
The next client will have more aggressive fallback support that should allow for most fonts on your system to be used. If you have a font with the character you want the next client should end up using it.
Nothing extracted yet.
Someone pasted this https://gist.github.com/4523901 into group chat, and it triggers the error below. The assertion continues to fill the terminal with any mouse-over activity, or further conversation, until the content has scrolled out of view.
Sysinfo: https://gist.github.com/4510990