Description of problem: with 2.12.91-2 xterm looks unnatural with truetype fonts (stretched) downgrading to 2.12.6-4 fixes the issue Version-Release number of selected component (if applicable): 2.12.91-2 How reproducible: start xterm, in the menu select "truetype fonts" Steps to Reproduce: 1. 2. 3. Actual results: stretched Expected results: not stretched Additional info:
did you see any different result of fc-match between 2.12.6-4 and 2.12.91-2? can you see any error or warning messages on the terminal when you run xterm? If you can't see any difference for the above, please attach both logs of FC_DEBUG=8 xterm with 2.12.6-4 and 2.12.91-2.
Created attachment 1375599 [details] FC_DEBUG=8 xterm with 2.12.6-4 FC_DEBUG=8 xterm with 2.12.6-4
Created attachment 1375601 [details] FC_DEBUG=8 xterm with 2.12.91-2 FC_DEBUG=8 xterm with 2.12.91-2
When i do a diff -u, this kind of stands out + variable: False(w)
That shouldn't affect on xterm I suppose. When you revert fontconfig to 2.12.6, did you also revert freetype too?
No, just fontconfig
Oops, sorry, I meant FC_DEBUG=7.
Created attachment 1375722 [details] FC_DEBUG=7 xterm with 2.12.6-4
Created attachment 1375723 [details] FC_DEBUG=7 xterm with 2.12.91-2
Thanks. I've tracked it down. matching rules which was added during <include> was evaluated prior to rules added before <include>. so even though xterm is requesting "mono" - which is usually corrected to "monospace" by the rule in fonts.conf - 2.12.91 is adding "sans-serif" because none of "sans-serif", "serif", "monospace" is in the pattern, then evaluating a rule to replace "mono" to "monospace" at the end. so 2.12.91 is returning a sans-serif font instead of monospace. Anyway, will fix that shortly.
should be fixed in 2.12.92-1. please test.
Confirmed. Thanks