Created attachment 135123 [details]
pt_BR installation

Confirming with transaltors.

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

Could anyone figure out if this is the redering issue from anaconda?

Please provide more similar examples along the anaconda process with pt_BR?

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.

Created attachment 136232 [details]
stage 1 of anaconda

Created attachment 136234 [details]
the text still has problem at the exit of anaconda.

Created attachment 136235 [details]
problem doesn't not appear in stage 2 (GUI)

Created attachment 136236 [details]
problem doesn't not appear in stage 2 (GUI)

Does it occur in the second stage of a text mode install?  Can you see the same
behavior in newt-based apps post-install?

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.

The problem also occurs in the second stage of a text mode install.

Caius, can you see if other newt-based apps are okay or not?

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.

Created attachment 137305 [details]
system-config-securityleve-tui in tty (virtual ternimal)

Problem exists, check the "cao" characters on the title of dialog.

Created attachment 137307 [details]
system-config-securityleve-tui in gnome

Problem does not exists.

Created attachment 137308 [details]
`setup` in tty.

Same problem.

Created attachment 137309 [details]
Menu in `setup` on tty.

Problem exists.

It might possible that functions used in "slang library" by newt got problem.

showchar.c of newt might responsible to character output on screen.

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.

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.

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.

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.

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.

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

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?

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.

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.

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.

Bug #208796 is new bug submitted for request fix of 'ã' in all console fonts
within kbd.