After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 82979 - Font selection does not allow selection of font style
Font selection does not allow selection of font style
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
1.9.x
Other Linux
: Normal minor
: future
Assigned To: Havoc Pennington
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-05-25 09:20 UTC by Luca Barbato
Modified: 2002-12-13 17:31 UTC
See Also:
GNOME target: ---
GNOME version: 2.0


Attachments
proposed patch which fixes the above problem (2.44 KB, patch)
2002-07-04 12:47 UTC, Pasupathi
none Details | Review

Description Luca Barbato 2002-05-25 09:20:02 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^^
Comment 1 Jeremy Nickurak 2002-06-03 21:00:10 UTC
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.
Comment 2 Luis Villa 2002-06-03 21:11:38 UTC
I can't quite call this 'high' but agreed that it is pretty
borderline. Up to you, really, Havoc.
Comment 3 Joseph Carter 2002-06-13 04:16:30 UTC
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?)
Comment 4 Havoc Pennington 2002-06-13 04:34:23 UTC
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.
Comment 5 Havoc Pennington 2002-06-13 05:38:17 UTC
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.
Comment 6 Calum Benson 2002-06-20 14:59:19 UTC
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.
Comment 7 Havoc Pennington 2002-06-20 18:06:11 UTC
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.
Comment 8 bill.haneman 2002-06-20 18:26:32 UTC
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 ?
Comment 9 Havoc Pennington 2002-06-20 18:54:51 UTC
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. ;-)
Comment 10 Pasupathi 2002-06-21 05:37:01 UTC
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?
Comment 11 Havoc Pennington 2002-06-21 12:30:21 UTC
The original bug still stands as far as I know, Calum just brought up
the additional issue of "use system font" being confused.
Comment 12 Pasupathi 2002-06-26 19:15:49 UTC
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.
Comment 13 Joseph Carter 2002-06-27 01:59:36 UTC
Will this include 75 and 100dpi fonts?
Comment 14 Pasupathi 2002-06-28 06:04:30 UTC
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.
Comment 15 Pasupathi 2002-06-28 06:13:40 UTC
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?
Comment 16 Pasupathi 2002-06-28 07:03:35 UTC
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"
Comment 17 Havoc Pennington 2002-07-04 03:55:34 UTC
Sane solution is to use VTE instead of zvt, or fix zvt to use fontconfig 
fonts.
Comment 18 Pasupathi 2002-07-04 12:43:17 UTC
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.

Comment 19 Pasupathi 2002-07-04 12:47:39 UTC
Created attachment 9631 [details] [review]
proposed patch which fixes the above problem
Comment 20 Calum Benson 2002-07-11 16:07:34 UTC
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?

Comment 21 Calum Benson 2002-07-11 16:09:35 UTC
Hmm, actually I see this also happens with the "use same colors as
other apps" setting, so is this a more general libzvt bug?
Comment 22 Havoc Pennington 2002-07-11 16:59:13 UTC
Lack of instant change is a gnome-terminal bug.
Comment 23 Havoc Pennington 2002-07-12 21:17:27 UTC
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.
Comment 24 Calum Benson 2002-09-10 13:13:35 UTC
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 :)
Comment 25 Havoc Pennington 2002-09-22 19:09:06 UTC
Punting off my radar, I'm taking patches but 
otherwise I'm in fontconfig/Xft2 land.
Comment 26 Calum Benson 2002-09-24 12:35:23 UTC
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?
Comment 27 Hidetoshi Tajima 2002-09-26 18:35:55 UTC
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.
Comment 28 Luis Villa 2002-12-03 22:21:24 UTC
Removing high priority to help clear havoc's queries a bit more. Pasu,
did this get fixed? can it be closed?
Comment 29 Pasupathi 2002-12-04 06:20:59 UTC
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?   
Comment 30 Calum Benson 2002-12-13 17:31:00 UTC
All works for me these days, in both Sun build and head... pls reopen
if you're still having problems.