Tested with Swedish.
On the firstboot "Display" screen, a dropdown box with resolution
choices is shown. The resolutions are written on the form "1024x768",
i.e. with an x character.
In both the ISO-8859-1 and UTF-8 character sets, there is a real
multiply sign (Ã) that can be used instead. All sane fonts also
include this sign by default.
The character is in Unicode called "U+00D7 MULTIPLICATION SIGN" and is
in UTF-8 coded as "0xC3 0x97" or in octal "\303\227".
I propose that either the firstboot source be changed so that the
resolutions are written with a real multiply sign, or that the
resolutions be marked for translation so that translators can correct
this in their translations.
This is more complicated that it might appear the settings are very
closely tied to Xorg based on what avaialable resolutions are.
To the best of my knowledge xorg.conf does not support U+00D7 within a
resolution string. As x is what will be in the xorg.conf this doesn't
seem like a show stopper. Adding to tracking bug. but as we're in
freeze for test2 will look at post freeze.
It is not my report from the beginning, but I do not think Christian's
intention was to use a multiplication sign in the generated xorg.conf
file. I believe he only referred to the user interface. There it
would appropriate with a multiplication sign.
Yes, I'm talking about UI only.
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.
This is still the case in the current release.
I did take a quick look at the code. The available resolutions are apparently
not explicitly listed in there. But I don't know Python well enough to
understand how they are computed.
Are the strings taken more directly from the X configuration? If so, comment 1
could be more relevant than I understood before. But I would like to understand
what actually happens here.
(In reply to comment #5)
> Are the strings taken more directly from the X configuration? If so, comment 1
> could be more relevant than I understood before. But I would like to understand
> what actually happens here.
They are, but we do get a chance to munge them before display. Strictly
speaking X doesn't care about unicode, at least for this. 0xC397 doesn't look
like a string termination, so it'll still strcmp right. In order to really fix
this you need to also fix rhpxl to know how to split up mode names on the
unicode X too; but my quick hack attempt does not appear to have worked.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
I started up system-config-display-2.2-1.fc12.x86_64 and it certainly still looks like an "x" rather than a multiplication sign to me. So this enhancement (it's not really a "problem") could still be done.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.