GNOME Bugzilla – Bug 633680
Improve text rendering in showing keyboard layout
Last modified: 2010-12-21 15:09:21 UTC
Please, improve text rendering in showing keyboard layout. The texts on the buttons are abbreviated with ... when they are took long for they key outline in which they are rendered in. Sometimes the abbreviation results in unreadable texts which makes this a bug since detailed keyboard model and key binding development is influenced. See first two attachments. Also note also that sometimes Shift_R is abbreviated and sometimes not. Please display all texts on keys of 6 or more characters in 50% font size compared to texts on keys that consist of 5 or less character. Also render texts that are not on key outlines in the font they should be rendered in. See the third attachment from xkbprint in which the vendor name and LED names are rendered with the correct font size. This font size can be found in the keyboards geometry file. Implementing this will greatly improve showing a keyboards layout and also aid in the development of new keyboard models.
Created attachment 173617 [details] Showing keyboard layout full screen
Created attachment 173618 [details] Showing keyboard layout half screen
Created attachment 173619 [details] xkbprint showing properly sized verdor label and LED labels
> Also note also that sometimes Shift_R is abbreviated and sometimes not. As you may guess, this is based on Pango metrics. If the text becomes too large - the ellipsis is added automatically by Pango (I just allow Pango to do so). I would consider that as a feature, not a bug. > Please display all texts on keys of 6 or more characters in 50% font size > compared to texts on keys that consist of 5 or less character. This is risky heuristic. Why is the threshold 5? > Also render texts that are not on key outlines in the font they should be > rendered in. See the third attachment from xkbprint in which the vendor name > and LED names are rendered with the correct font size. This font size can be > found in the keyboards geometry file. There may be some problems here, with the fonts. According to what I see in debug, XKB provides X11 font name -*-helvetica-medium-r-normal--*-120-*-*-*-*-iso8850-1. I will check how to get Pango-compatible font size from that string. Unfortunately, there is no explicit font size in XkbTextDoodadRec (check XKBgeom.h). Also, since we are using the font, compatible with the current GTK theme, the font from geometry can be quite different - so even if I obtain the size from X11 font description (recommended by XKB), that size can be wrong for the actual font we use in Pango (the image would look wrong).
(In reply to comment #4) > > Also note also that sometimes Shift_R is abbreviated and sometimes not. > As you may guess, this is based on Pango metrics. If the text becomes too large > - the ellipsis is added automatically by Pango (I just allow Pango to do so). I > would consider that as a feature, not a bug. > > > Please display all texts on keys of 6 or more characters in 50% font size > > compared to texts on keys that consist of 5 or less character. > This is risky heuristic. Why is the threshold 5? In retrospective, 2 or more is better. Just look at your/any keyboard. Only texts on keys of 1 character are in a certain font that is approximately 50% bigger then the texts F1, Tab, Caps Lock, Enter, Shirt, Alt, Ctrl, Page Up, Home, etcetera. the only risk involved is that some text might be too small. But this risk can be controlled by implementing this, generating images for all keyboards (not so many in xkb) and visually confirm that overall the all look much better. > > Also render texts that are not on key outlines in the font they should be > > rendered in. See the third attachment from xkbprint in which the vendor name > > and LED names are rendered with the correct font size. This font size can be > > found in the keyboards geometry file. > There may be some problems here, with the fonts. > According to what I see in debug, XKB provides X11 font name > -*-helvetica-medium-r-normal--*-120-*-*-*-*-iso8850-1. I will check how to get > Pango-compatible font size from that string. Unfortunately, there is no > explicit font size in XkbTextDoodadRec (check XKBgeom.h). Also, since we are > using the font, compatible with the current GTK theme, the font from geometry > can be quite different - so even if I obtain the size from X11 font description > (recommended by XKB), that size can be wrong for the actual font we use in > Pango (the image would look wrong). Helvetica is not something found on the average machine running GNOME. I'm sure there must be a better default. Thanks for taking all this into consideration. I would be happy to test anything you implement regarding this.
> In retrospective, 2 or more is better. Just look at your/any keyboard. Only > texts on keys of 1 character are in a certain font that is approximately 50% > bigger then the texts F1, Tab, Caps Lock, Enter, Shirt, Alt, Ctrl, Page Up, > Home, etcetera. Ghm. I will check what it looks like... > be controlled by implementing this, generating images for all keyboards (not so > many in xkb) and visually confirm that overall the all look much better. There are many keyboard - much more than I am willing to control manually. Especially - with all possible layouts. Not an option. > Helvetica is not something found on the average machine running GNOME. I'm sure > there must be a better default. That's my point. Currently we're totally ignoring the font provided by XKB (helvetica, size etc). We are using the GNOME font, from the theme. But if I pick the size supplied by XKB with font supplied by GNOME - we might have a mess... Anyway, that is only possible if I manage to extract the size from the X11 font string.
I made all lengthy text fragments "x-small". Looks nicer IMHO. Please check from git
Thanks.