Bug 97796

Summary: Bad turkish fonts in GUI install
Product: [Retired] Red Hat Linux Beta Reporter: David Balažic <david.balazic>
Component: anacondaAssignee: Jeremy Katz <katzj>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: alpha 2CC: erc.caldera, otaylor
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-24 18:39:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 100643    

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
3.
    
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

fontconfig-2.1-9.i386.rpm
fontconfig-devel-2.1-9.i386.rpm
freetype-2.1.3-9.i386.rpm
freetype-demos-2.1.3-9.i386.rpm
freetype-devel-2.1.3-9.i386.rpm
freetype-utils-2.1.3-9.i386.rpm
urw-fonts-2.0-29.noarch.rpm


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.