I am not using xft fonts at the moment, but I was not able to
get the error on my system with the font/size you mentioned.
But randomly trying fonts and sizes *did* find some non-xft
fonts that have invisible underscores, like Wenquanyi zen hei,
where size 5,6,7 don't have underscores, 9 appears correct,
then 10 says Wrong type argument: font-instance-p nil, in the
minibuffer, 11 looks ok, and 12 is ok, then 13 says Wrong
type argument: font-instance-p nil in the minibuffer, and so on.
So invisible underscores might not just be a problem in xft fonts?
Just wondering if that might be related, that is, some font/size
situations refreshing 1 extra line of pixels too far apart between
lines, leaving droppings I occasionally see, and other font/size
situations refreshing 1 extra line of pixels too close to the line
above, eliminating(maybe by overwriting) underscores?
I wish I knew more about screen refresh and how it chooses
the height of a line in a certain font/size. Maybe there is some
rounding up and down going on for different sizes of fonts.
On 04/06/2013 06:40 PM, Mats Lidell wrote:
>>>>> smitchel <smitchel(a)bnin.net> writes:
> Maybe you have done this already, but does it stay the same with
> both different sizes of the same font (12,14,16,18,29, etc)? And
> does it change if you try different fonts?
No I had not done that but now I have.
Apparently the font I use, DejaVu Sans Mono-10, has this problem only
at the size of 10. Using a smaller or larger size of DejaVu Sans Mono
works fine. I tested also with other fonts with this size and they
work fine. So changing the font or the size will solve it, the
underscore problem, for me.
(But might give other problems. Editing this text now with "Liberation
Mono" and it seems more likely to trigger tall characters being cut of
but here ^L seems to help anyway!)
XEmacs-Beta mailing list