Bug 97796 - Bad turkish fonts in GUI install
Summary: Bad turkish fonts in GUI install
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: alpha 2
Hardware: All Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
: 106235 (view as bug list)
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
Reported: 2003-06-21 11:07 UTC by David Balažic
Modified: 2007-04-18 16:54 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-24 18:39:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description David Balažic 2003-06-21 11:07:43 UTC
Description of problem:

After selecting Turkish language in GUI install, the text
is weird. Like if the wrong font were used. Some chars are
printed as a square with 4 digits in it.

Version-Release number of selected component (if applicable):

Cambridge alpha2

How reproducible:

Steps to Reproduce:
1. start GUI install
2. select Turkish language
Actual results:

Some bad characters

Expected results:

No bad characters

Additional info:

Comment 1 Jeremy Katz 2003-06-23 16:42:57 UTC
This was fine in Shrike I believe...  Owen, do you know of any relevant changes?

Comment 2 Owen Taylor 2003-06-23 16:51:54 UTC
What urw-fonts, fontconfig, and FreeType versions?

Comment 3 Jeremy Katz 2003-06-23 16:55:39 UTC
A2 had


Comment 4 Owen Taylor 2003-06-23 17:54:57 UTC
Hmm, those are the same versions as in Red Hat 9. Are you sure
you didn't remove some fonts from the install image that were
there in 9?

Comment 5 Jeremy Katz 2003-08-06 21:10:55 UTC
Same fonts are present.  And still happening with current trees.

Comment 6 Owen Taylor 2003-08-06 21:38:48 UTC
Can you provide a string that doesn't display correctly? (perferably
as an attachment to avoid bugzilla encoding mangling)

Comment 7 David Balažic 2003-08-07 06:31:45 UTC
I case that was addressed at me : no.

I just started the GUI install in Turkish language and the problems were right 
there, obvious. Probably on the first page, if not then somewhere in the first 
5 pages ( I don't recall anymore ) . I did not perform a complete Turkish 
install. I don't know turkish.

Comment 8 Owen Taylor 2003-08-07 13:53:42 UTC
Well, it was addressed at whoever wanted to dig up the Anaconda .po
files, and correlate them with the particular strings that were
misdisplaying. Mostly at Jeremy.

Comment 9 Jeremy Katz 2003-10-03 21:08:40 UTC
*** Bug 106235 has been marked as a duplicate of this bug. ***

Comment 10 Jeremy Katz 2003-10-16 00:54:46 UTC
Oh, ick.  Worked around in rhpl for now.

Basic cause is that python's gettext looks at mofiles to find
project-id-version.  It string.lower()'s the string from the mofile itself and
then compares against the lowercase version.  With Turkish, this becomes
"project-Id-version" (that is, lower("I") = "i") and so no metadata is gathered
and then rhpl was falling back to assuming iso8859-1. 

Sent misa the python patch to look at and changed rhpl.translate to assume UTF-8
instead as that's a safer plan with our current locale strategy.

Comment 11 Jeremy Katz 2006-04-24 18:39:39 UTC
Mass-closing lots of old bugs which are in MODIFIED (and thus presumed to be
fixed).  If any of these are still a problem, please reopen or file a new bug
against the release which they're occurring in so they can be properly tracked.

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