Bug 89446 – Default font not loaded in non-unicode locale

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 89446 - Default font not loaded in non-unicode locale

Summary:	Default font not loaded in non-unicode locale

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	initscripts (Show other bugs)
Sub Component:
Version:	9
Hardware:	athlon Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Bill Nottingham
QA Contact:	Brock Organ
Docs Contact:

URL:
Whiteboard:
Keywords:

Duplicates:	75564 (view as bug list)
Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2003-04-22 18:54 EDT by Carlos Rodrigues
Modified:	2014-03-16 22:35 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-09-29 16:37:54 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
loads console font even when the locale is not unicode (1.24 KB, patch) 2003-07-27 17:50 EDT, Carlos Rodrigues	no flags	Details \| Diff
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Carlos Rodrigues 2003-04-22 18:54:38 EDT

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
I'm not using an utf-8 locale (because I lose the accented characters in the
console, bug #75430) and thus I am defining another font for the console. The
problem is that this font is not loaded on vt's other than the first. I see that
for unicode locales, /etc/profile.d/lang.sh takes care of loading $SYSFONT on
the other vt's but if the locale is not unicode this does not happen.


How reproducible:
Always


Additional info:

The contents of /etc/sysconfig/i18n:

LANG="en_US"
SUPPORTED="en_US.UTF-8:en_US:en:pt_PT.UTF-8:pt_PT:pt"
SYSFONT="lat9w-16"
CHARSET="8859-15"

LC_COLLATE="pt_PT@euro"
LC_CTYPE="pt_PT@euro"
LC_MONETARY="pt_PT@euro"

Comment 1 Carlos Rodrigues 2003-07-27 17:50:01 EDT

Created attachment 93182 [details]
loads console font even when the locale is not unicode

I changed the lang.sh and lang.csh scripts a bit to load the default console
font even when the locale is not unicode.

Comment 2 Bill Nottingham 2003-09-03 21:12:55 EDT

This shouldn't be necessary; what problem are you seeing without this?

Fonts don't really need to be called for each console; setting it once should
suffice (the reason unicode_start is called is because there are other issues
that it takes care of.)

Comment 3 Carlos Rodrigues 2003-09-04 07:31:57 EDT

I'm defining the font lat9w-16 for the console because it has accented
characters (like &aacute; for instance). But (without my changes to lang.sh) it
is only defined for the first vt, so, if I press "Â´ + a" in the first vt I see
"&aacute;", but if I do the same in the other vt's I see "a".

Comment 4 Carlos Rodrigues 2003-09-06 22:02:57 EDT

I made a little mistake in my previous comment. Actually "&aacute;" (Ã¡) displays
ok but some characters which have a tilde - like "&atilde;" (Ã£) and "&otilde;"
(Ãµ) do not. Besides this small detail (maybe next time I will reproduce the
problem again instead of trusting my memory of it) my point remains the same.

Comment 5 Carlos Rodrigues 2003-09-06 22:23:01 EDT

*** Bug 75564 has been marked as a duplicate of this bug. ***

Comment 6 Bill Nottingham 2005-09-29 16:37:54 EDT

Closing bugs on older, no longer supported, releases. Apologies for any lack of
response.

I suspect this was due to a kernel bug, which we worked around in previous releases.

The kernel bug was fixed in 2.6.13 and later.

Note You need to log in before you can comment on or make changes to this bug.