fvwm3 icon indicating copy to clipboard operation
fvwm3 copied to clipboard

Do not calculate size for missing characters.

Open topcat001 opened this issue 2 years ago • 0 comments

This is my understanding of the situation: When the code in MatchFont decides that the chosen font does not have the character in question, it constructs a fallback font from the properties of the original. Then, it reports the dimensions of the character and also renders it using this new fallback font. Mostly this works fine. I checked this by debugging through the code character by character.

However, the only exception I found is for characters with codelen = 4. There might be other cases but I could not reproduce this in my tests with other types of chars. In this case calling XftCharExists on the char with the fallback font will return true and XftTextExtents32 will return some reasonable looking values, but the character actually does not render using the fallback font when render_char is called next. This is the case which throws BadLength.

For FvwmIdent, in fact during the MakeList call when no rendering is done, XftTextExtents32 is called for these problematic characters using the fallback font. This is enough to cause a BadLength error during the Xlib calls here.

In my test fix I skip over these characters if a fallback is active. This avoids the Xlib BadLength error which caused the crash. Of course this test is too simplistic, but maybe we can find a better way to detect and skip such non-rendering characters. Please have a look, thanks!

Fixes #622, fixes #680.

topcat001 avatar Aug 02 '22 19:08 topcat001