GNOME Bugzilla – Bug 74969
I can't use -schumacher-clean fonts with gnome-terminal anymore
Last modified: 2004-12-22 21:47:04 UTC
Package: gnome-core Severity: minor Version: 1.4.0.6-1.ximian.2 Synopsis: I can't use -schumacher-clean fonts with gnome-terminal anymore Bugzilla-Product: gnome-core Bugzilla-Component: gnome-terminal Description: I recently installed gnome-core-1.4.0.6-1.ximian.2 via Red Carpet, and now gnome-terminal ignored my atempts to set a font in the -schumacher-clean family. Other applications like emacs or xterm use such fonts perfectly well, and they show up in the font selection section. gnome-terminal just ignores attempts to switch to them. Actually, it doesn't 'ignore' them exactly. The font it's using on screen doesn't change, but the font listed in the 'preferences->General' dialog is the new font. If I disable 'multibyte' support, it switches OK. If I switch, then turn on multibyte support, it remains schumacher-clean. schumacher-clean is my favorite font family because it looks so good with tiny characters and it has /'d 0s. Great for programming. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-03-16 13:32 ------- The original reporter (eric-gnome@omnifarious.org) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, gnome-core-maint@bugzilla.gnome.org.
I'm considering disabling multibyte support as default. This would "fix" the problem for you, no?
It would 'fix' it, I suppose, just to leav me to stumble over it again when I forgot and turned on the option. I guess I think the ideal solution would be to somehow making choosing a font that isn't supported by the multibyte code (let me guess, iso-8859-1 or iso-10646 encoding?) and turning on the multibyte option should somehow be mutually exclusive. Perhaps the multibyte option could be greyed out when an incompatible font is selected, ideally with a 'font not supported' note or something. I would imagine its hard to do anything to the font selection dialog as it's a standard GNOME dialog. Of course, maybe my theory on why the problem is happening is all wrong. :-)
Could the ownership of this bug be changd to me as I'm the original reporter. I think the NEEDINFO state is no longer the appropriate one.
We only assign bugs to the people who are supposed to fix them. The reason it shows unknown@bugzilla.gnome.com as the reporter is that you haven't registered for an account in bugzilla.
I do have an account here now. Could that account be assigned as the reporter?
I don't think that's possible, but I'll add you to the Cc: field.
I'm probably going to make multibyte turned off for the next release. The support seems a bit broken anyway.
This should be fixed in 2.0.x. Confirm?
Yes, 2.0.1 seems to have a completely different means of dealing with the problem. In fact, it isn't clear to me that 2.0.1 even supports multibyte character sets yet. Since I'm an english speaker, I don't use multibyte character sets at all, and this is hard to test. But, at least it doesn't mysteriously choose to use or not use a font based on some other setting that appears to have no connection at all.
Depending on having libzvt compiled from the libzvt-i18n branch or using vte as the terminal widget it should work with multibyte.
Well, I'm using the RH 8.0 version, and using ldd on it, it doesn't appear to link in libzvt. I don't know how to tell if it's using vte as the terminal widget. I do know the terminal widget has some interesting problems that I'm not sure how to accurately describe or replicate. But, that should be in a different Bugzilla report.
Red Hat uses vte (developed by RH actually) and that should support multibyte if I remember correctly
I'm not sure how to test the multibyte support of vte. Anyway, this bug should be marked closed as its no longer relevant to gnome-terminal 2
Closing as fixed in 2.x then. Thanks.