GNOME Bugzilla – Bug 82979
Font selection does not allow selection of font style
Last modified: 2002-12-13 17:31:00 UTC
the current fonc selection mode is quite rescrictive, I use to have a medium font as console font, I can't chose it from there since there are just the bold and the normal option. a gtk font selector popup button may be good^^
In particular, the bug seems to be that gnome-terminal's font selector lacks any means to specify the "style" (as gnome-font-properties' dialog referse to it), outside of selecting whether or not to use bold. This prohibits the user from selecting (among other styles), the fixed misc semicondensed terminal font that so many users are used to as the default for xterm. Setting to high priority/minor severity given that this is an irratating regression from 1.4 behavior.
I can't quite call this 'high' but agreed that it is pretty borderline. Up to you, really, Havoc.
Additionally, this or some annoyingly similar limitation prevents the selection of basically any 75dpi font on my system. A great many X11 fonts are available only in 75dpi form, and while the font in question may be carefully entered by hand into the /apps/gnome-terminal/profiles/Default/x_font key, it is guaranteed to be broken the moment you even look at the font config settings in the preferences dialog, with no way to revert to the previous readable setting. This problem causes a great many large fonts to simply not be available, including the only charcell font large enough for me to actually read. This is not a minor buglet for those such as myself who are simply unable to read any of the available fonts. It really does need fixing or low-vision users are going to find gnome-terminal to be completely useless without digging through gconf keys that a new user would probably not even know exist. Please change the severity appropriately (or better yet, fix the bug?)
My general plan is to fix this by moving to a widget that allows using the Pango font selector (as when compiling gnome-terminal --with-widget=vte). Or by hoping someone will adapt libzvt to work with the Pango selector. I'd take a patch to enhance the current selector, but since I already have the VTE-based terminal in Rawhide, it's just not on top of my queue.
I haven't looked but it's possible this is just an issue with the filters applied in the font selector code. May be a simple fix.
Is it this bug that's causing the "use same font as other applications" checkbox to apparently have no effect whatsoever? This is an accessibility stopper.
That button doesn't work because your system font probably is not monospaced. The terminal can only use monospace fonts. So it is trying to locate the monospace font which is most similar in size and other properties to your system font. If you have a large system font, and have a similar monospace font at the same large size, you should get the large monospace font. But if it doesn't, debugging it would require looking at the exact fonts involved to see what goes wrong. I believe the correct solution is to have a system monospace font, i.e. a "Monospace Font" setting in the Fonts control panel, so the terminal doesn't have to use heuristics to find a monospace font similar to your system font.
interesting diagnosis, Havoc. On Solaris the font matching algorithm must be *really* broken, since the 'best match' picked for an 18 point Sans font appears to be about a 9 point monospace. I tend to agree that the ultimate best solution for the terminal font is to have a "system monospace" font; now, how do we build consensus for that in GNOME 2.0.X ?
The algorithm may well be really broken, might be worth having a look. My opinion is that the "system monospace" font is a new feature, and thus on 2.1.x. I am pushing aggressively to avoid getting stuck on 2.0.x. Bugfixes only. I want the system monospace patch in Red Hat though, we'll be backporting it to 2.0.x in our vendor patches. I believe the main blocking issue right now (for this and also control center metacity support) is lack of a 2.1.x branch in the control-center module. I don't think it would be crazy to add this and metacity support to control-center and make an initial 2.1.x development release that happens to be quite stable. ;-)
Havoc: Initially this bug was created to provide additional fonts in the terminal. But now I guess this has taken a new direction of having "system monospaced" font. So is that the case if the "use same font as other application" works correctly then this bug would be resolved or as you mentioned earlier it needs some filters to be removed in the font selector code?
The original bug still stands as far as I know, Calum just brought up the additional issue of "use system font" being confused.
I am modifying the filter to include all available fonts supported by libzvt (monospaced etc). It will include semicondensed fonts also. I hope that should solve the issue and user will have many fonts and fonts of different style (simecondensed, medium semicondensed etc) to choose from.
Will this include 75 and 100dpi fonts?
I have tried the following solution: Currently the fontselector code in gnome-terminal tries to display, one style per fontfamily-foundry. So I tried to display all the available styles for the fontfamily-foundry. This causes the following problems 1. The GUI doesn't looks bad with two many fonts listed with it. Most of the users won't like this kind of listing. 2. Again in the list most of the fonts are not loadable (this may vary with the xserver). So listing many and many of them are not loadable means again it is not a good thing to see. For resolving the problem 2, we can set filters to the encoding field thereby we may reduce the fonts to some extent. But with this filter we may loose some fonts which are there currently. I don't know if the users will accept this. Currently the *fixed(misc)* font in gnome-terminal is a "semicondensed font". Coming to 75dpi I don't see any filters for the resolution field in the XLFD format. It actually has -*-*- . So I guess xserver will automatically substitute the fonts which they are having. May be if you want 75dpi fonts then I think the xserver fontpath must be set to that directory containing 75dpi. But again am not too sure about this issue.
The best possible solution for this is to provide a gtk font selector. But currently this is not possible because the terminal uses only monospaced/charcell fonts. Also as Havoc, mentioned libzvt doesn't have pango font support. Hence we cann't give pango supports in this case. Havoc: any idea what could be the shane solution for this?
Typo error!!! "The GUI doesn't looks bad with two many fonts listed with it" "The GUI doesn't look _good_ with _too_ many fonts listed with it"
Sane solution is to use VTE instead of zvt, or fix zvt to use fontconfig fonts.
Havoc: Per Calum and Bill currently the "Use the same font as other application" is broken. I debugged the code and found the following issues 1. The function xlfd_get_nth_field() currently doesn't pick up the correct value, because the XLFD indices are assigned values assuming the first entry will start from zero. But g_strsplit function puts the first entry as NULL because delimiter is present at the start of the string. (E.g. string: -adobe-helvetica-bold-r-normal--10-100-75-75-p-60-iso8859-1 ) Due to the above mentioned problem make_xfont_have_size_from_other_font doesn't pick up the pixel size correctly. Hence the function fails in almost all the cases, causing no effect to the "use same font as..." check box. 2. Also to get the point size, it is passing wrong position. ie. it should be XLFD_SIZE_IN_POINTS_INDEX instead of XLFD_SIZE_IN_PIXELS_INDEX. I have corrected these problems and tested the same in linux and solaris.
Created attachment 9631 [details] [review] proposed patch which fixes the above problem
I just tried this patch (only on Linux though) and it certainly seems to pick better fonts than the old version. However when I change the system font in the Fonts or Themes Preferences dialog, the change doesn't take place immediately in the terminal-- I have to uncheck the "use same font as other apps" box in gnome-terminal profile dialog, then re-check it again. Is this expected, and is there any way we can make the change happen instantly?
Hmm, actually I see this also happens with the "use same colors as other apps" setting, so is this a more general libzvt bug?
Lack of instant change is a gnome-terminal bug.
Applied Pasupathi's patch, and fixed things to update when you change the font in the Font control panel. I'm not sure what else is pending here, or exactly how to fix it, so closing bug. I guess the only reasonable solution in my mind is to get the monospace font in the Font control panel, and get gnome-terminal using the same Pango font system as everything else. Which is already done in the form of VTE.
On Solaris 8, GNOME beta 2, build 6: If you select "use same font as other applications", nothing happens. This somewhat works on linux, by picking a monospaced font and scaling it up to something nearer your gtk theme font size, but it does absolutely nothing at all on Solaris as far as I can see. Re-opening until somebody tells me it's not *supposed* to do anything on Solaris :)
Punting off my radar, I'm taking patches but otherwise I'm in fontconfig/Xft2 land.
I don't blame you for punting it :) However for Sun this in conjunction with bug #81900 is pretty much an accessibility stopper for FCS, assuming we haven't switched to vte by then Any chance you could re-investigate, Pasu?
libzvt-i18n branch uses pango font. If libzvt-i18n changes can be merged to the HEAD, I also want to make a patch to gnome-terminal HEAD to enable Pango font for libzvt.
Removing high priority to help clear havoc's queries a bit more. Pasu, did this get fixed? can it be closed?
I don't really see any problems on my linux box. Also I don't see any problem in our fcs builds on Solaris machines (I think Hidetoshi fixed it in our branch). Calum can you pls. confirm this and close the bug?
All works for me these days, in both Sun build and head... pls reopen if you're still having problems.