Bug 204470 - [pt_BR] [tui] Rendering is incorrect for accent chracter
[pt_BR] [tui] Rendering is incorrect for accent chracter
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kbd (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: i18n
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-08-29 08:37 EDT by A S Alam
Modified: 2013-07-02 20:39 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-01 10:38:53 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)
pt_BR installation (17.30 KB, image/jpeg)
2006-08-29 08:54 EDT, A S Alam
no flags Details
stage 1 of anaconda (80.74 KB, image/png)
2006-09-14 01:06 EDT, Caius Chance
no flags Details
the text still has problem at the exit of anaconda. (372.75 KB, image/png)
2006-09-14 01:08 EDT, Caius Chance
no flags Details
problem doesn't not appear in stage 2 (GUI) (164.21 KB, image/png)
2006-09-14 01:09 EDT, Caius Chance
no flags Details
problem doesn't not appear in stage 2 (GUI) (173.00 KB, image/png)
2006-09-14 01:11 EDT, Caius Chance
no flags Details
system-config-securityleve-tui in tty (virtual ternimal) (120.90 KB, image/jpeg)
2006-09-28 07:17 EDT, Caius Chance
no flags Details
system-config-securityleve-tui in gnome (104.27 KB, image/jpeg)
2006-09-28 07:18 EDT, Caius Chance
no flags Details
`setup` in tty. (107.77 KB, image/jpeg)
2006-09-28 07:20 EDT, Caius Chance
no flags Details
Menu in `setup` on tty. (110.17 KB, image/jpeg)
2006-09-28 07:21 EDT, Caius Chance
no flags Details
latarcyrheb-sun16.psfu.gz from kbd-1.12-18 (3.74 KB, application/octet-stream)
2006-10-01 10:11 EDT, Miloslav Trmač
no flags Details

  None (edit)
Description A S Alam 2006-08-29 08:37:37 EDT
Description of problem:
Rendering of accent character is not correct. Tested on Rawhide

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

How reproducible:
Everytime during installation's Stage1

Steps to Reproduce:
1. start installation
2. goto Media for Installation page
3. check Instala,c~ao (Installation)
  
Actual results:
instalaçao  (a)

Expected results:
instalação (ã) (string copy to translation file)

Additional info:
GUI is ok
Comment 1 A S Alam 2006-08-29 08:54:52 EDT
Created attachment 135123 [details]
pt_BR installation
Comment 2 Caius Chance 2006-09-11 01:39:11 EDT
Confirming with transaltors.
Comment 3 Valnir Ferreira Jr 2006-09-11 03:14:20 EDT
(In reply to comment #2)
> Confirming with transaltors.

This is a well-known issue. I checked the .op file and verified that this is a
rendering rather than a translation problem.

Comment 5 Caius Chance 2006-09-12 22:03:25 EDT
Could anyone figure out if this is the redering issue from anaconda?

Please provide more similar examples along the anaconda process with pt_BR?
Comment 7 Caius Chance 2006-09-14 01:02:18 EDT
If that is a rendering problem, if might only the issue in text-mode as it does
not happen in GUI stage of anaconda. (rawhide)

Please check the attached screenshot.
Comment 8 Caius Chance 2006-09-14 01:06:44 EDT
Created attachment 136232 [details]
stage 1 of anaconda
Comment 9 Caius Chance 2006-09-14 01:08:18 EDT
Created attachment 136234 [details]
the text still has problem at the exit of anaconda.
Comment 10 Caius Chance 2006-09-14 01:09:46 EDT
Created attachment 136235 [details]
problem doesn't not appear in stage 2 (GUI)
Comment 11 Caius Chance 2006-09-14 01:11:02 EDT
Created attachment 136236 [details]
problem doesn't not appear in stage 2 (GUI)
Comment 12 Jeremy Katz 2006-09-14 16:48:47 EDT
Does it occur in the second stage of a text mode install?  Can you see the same
behavior in newt-based apps post-install?
Comment 13 Caius Chance 2006-09-15 01:50:41 EDT
I just saw it in text-mode, when it entered the GUI page, it is just rendered
perfectly.

-----

There is a screenshot above which shows the problem still exists in test-mode
when I exited from anaconda manually selecting "No" to a question in anaconda.
Comment 14 Caius Chance 2006-09-21 00:36:20 EDT
The problem also occurs in the second stage of a text mode install.
Comment 15 Leon Ho 2006-09-25 23:06:42 EDT
Caius, can you see if other newt-based apps are okay or not?
Comment 17 Caius Chance 2006-09-28 07:14:35 EDT
The same problem is exists in system-config-securityleve-tui, setup, etc when
started in virtual terminal (Ctrl-Alt-1|2|3|...).

However, when I run in Ternimal on Gnome, problem doesn't exist.
Comment 18 Caius Chance 2006-09-28 07:17:24 EDT
Created attachment 137305 [details]
system-config-securityleve-tui in tty (virtual ternimal)

Problem exists, check the "cao" characters on the title of dialog.
Comment 19 Caius Chance 2006-09-28 07:18:59 EDT
Created attachment 137307 [details]
system-config-securityleve-tui in gnome

Problem does not exists.
Comment 20 Caius Chance 2006-09-28 07:20:14 EDT
Created attachment 137308 [details]
`setup` in tty.

Same problem.
Comment 21 Caius Chance 2006-09-28 07:21:18 EDT
Created attachment 137309 [details]
Menu in `setup` on tty.

Problem exists.
Comment 22 Caius Chance 2006-09-28 08:05:50 EDT
It might possible that functions used in "slang library" by newt got problem.

showchar.c of newt might responsible to character output on screen.
Comment 23 Caius Chance 2006-09-28 08:47:41 EDT
Ignore comment #22.

The console font "latarcyrheb-sun16.psfu.gz" which located in
/lib/kbd/consolefonts has problem on 'ã' (0xe3).

/etc/sysconfig/i18n specifies such font as default console font.

-----

Use NAFE (http://nafe.sourceforge.net/) which could confirm the problem.

1. Build NAFE.
2. Decompress latarcyrheb-sun16.psfu.gz.
3. Put decompressed .psfu file in same directory as NAFE binary file and run by
`psf2txt latarcyrheb-sun16.psfu output.txt`
4. Open output.txt by editor. e.g. `vi output.txt`
5. Search "0xe3" which is the hex number of 'ã'.
6. The bitmap shows such character without tilda (~) on top of 'a'.

-----

FYI, NAFE also has converter (txt2psf) which might could convert the output file
back to .psf file after minor fix. However, that method has not been tried yet.
Comment 24 Miloslav Trmač 2006-09-29 07:33:41 EDT
I have added a tilde to the font in kbd-1.12-18 (in dist-fc6-HEAD).  Can you
check it looks correctly, please?

Thanks in advance.
Comment 25 Caius Chance 2006-09-29 09:48:15 EDT
I will go back to office and test it.

FYI, I found another font included already installed which without the problem,
we could use that as default console font in case your fix still doesn't work.
All to do is just use /etc/sysconfig/i18n to point to such font:

<CONTENT OF i18n>
LANG="en_US.UTF-8"
SYSFONT="LatArCyrHeb-16"
<CONTENT ENDS>

-----

If that works, please let me to change bug status as "MODIFIED" for shorter
turnaround.
Comment 27 Caius Chance 2006-09-30 04:41:33 EDT
I have tested the font and it has been fixed.

However, I have found the same problem when I am using Japanese as the default
system language.

After the investigation on the /etc/sysconfig/i18n, it is pointing to another
font "latarcyrheb-sun16". I suspect the same problem may exists in more than one
fonts.

In my humble opinion, the problem is discovered with applicability of solution
be proved. Besides, personally I think the problem has not been fully fixed.

I understand it might be time consuming to check every console fonts to ensure
the problem is not in none of fonts. But once user's default font (specified in
/etc/sysconfig/i18n) is not pointing to latarcyrheb-sun16, problem might be
possible to happen.
Comment 28 Caius Chance 2006-09-30 04:48:38 EDT
Use Case:

1. Change system language to "Japanese".
2. Reboot.
3. Go to Console (Ctrl-Alt-F1).
4. Type `LANG=pt_BR.UTF-8 setup`
5. Problem exists as the console font has been changed as the system language is
changed.
6. open /etc/sysconfig/i18n, discovered that the default console font is
pointing to another font.
Comment 29 Miloslav Trmač 2006-10-01 10:06:36 EDT
> SYSFONT="LatArCyrHeb-16"
This font doesn't contain the Euro character, so I'd rather not have it as
a default.  I also think most people don't change the font, so LatArCyrHeb-16
wasn't tested much and might contain incorrect glyphs as well.

(In reply to comment #27)
> I have tested the font and it has been fixed.
_Which_ font have you tested?

> After the investigation on the /etc/sysconfig/i18n, it is pointing to another
> font "latarcyrheb-sun16".
kbd-1.12-18 has added the tilde to latarcyrheb-sun16.  Do you mean "it is
pointing to a different font than latarcyrheb-sun16"?  The language table in
s-c-language specifies lat0-sun16 for Japanese.

> I suspect the same problem may exists in more than one
> fonts.
There are only 512 glyph cells in each font (only 256 if you don't want to lose
8 of the 16 background colors), so most fonts contain a very small subset of
Unicode.  AFAIK latarcyrheb-sun16 has the largest Unicode coverage of all the
console fonts in kbd.

> In my humble opinion, the problem is discovered with applicability of solution
> be proved.
I'm sorry, I don't understand the sentence.
 
> I understand it might be time consuming to check every console fonts to ensure
> the problem is not in none of fonts.
Not only time-consuming, it is simply impossible.  A typical 256-glyph font can
cover a single ISO-8859-x code page and perhaps be compatible with a few legacy
national character sets, but certainly not cover the whole Europe or even the
whole world.

This is the case of sun0-16: it doesn't have a spare glyph where to place U+00E3
("ã"), so it at least maps U+00E3 to U+0061 ("a") because a missing tilde is
better than a black square.
Comment 30 Miloslav Trmač 2006-10-01 10:11:03 EDT
Created attachment 137500 [details]
latarcyrheb-sun16.psfu.gz from kbd-1.12-18

FWIW, this is the new font file.  Is this the one you have tested?
Comment 31 Caius Chance 2006-10-01 10:23:33 EDT
Yes that file has been fixed. :)

However, when we use other language as system language, the default console font
will be changed. (reflected by automate updation of /etc/sysconfig/i18n file)

Miloslav, thank you very much for your help. You could put this bug as MODIFIED
for QC.

-----

Regarding the problem above I discovered during the observation, we need to file
two new bug:

1. system-config-language, to ensure it uses "latarcyrheb-sun16.psfu.gz" as
default console font for all languages.
2. kbd, to ensure all console fonts in the package got the same problem fixed.
Comment 32 Miloslav Trmač 2006-10-01 10:38:53 EDT
Thanks, I have asked Fedora release engineers to use the new kbd package for FC6.

Regarding the two new bugs:

1. while latarcyrheb-sun16 has the largest coverage, it is not a superset of the
other fonts;  e.g. sun0-16 has more than 10 pseudographics characters that are
not present in latarcyrheb-sun16.  I guess in most cases the system-wide locale
will reflect preferences of root and most users, so using pt_BR in a Japanese
system is quite rare and it might be more useful to have a good coverage of the
characters that are actually used in the system language than a basic coverage
of other languages.

2. I have checked lat0-sun16 and lat2-sun16 (the other two fonts coming from the
same source), neither contains U+00e3.
Comment 33 Caius Chance 2006-10-01 19:51:40 EDT
Thank you for your valuable info and helps.

Regarding to the two new bugs:

1. As you mention about the coverage, it might be better to keep every language
be using their own default font. Therefore, I am not filing this as a new bug.

2. I understand the case might be rare, I hope you don't mind me to put the new
bug as low priority.
Comment 34 Caius Chance 2006-10-02 10:05:15 EDT
Bug #208796 is new bug submitted for request fix of 'ã' in all console fonts
within kbd.

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