[Fedora-i18n-bugs] [Bug 681750] New: No Language Selection/Language List in GDM
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: No Language Selection/Language List in GDM
https://bugzilla.redhat.com/show_bug.cgi?id=681750
Summary: No Language Selection/Language List in GDM
Product: Fedora
Version: 15
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Keywords: i18n
Severity: unspecified
Priority: unspecified
Component: gdm
AssignedTo: jmccann(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: jmccann(a)redhat.com, rstrode(a)redhat.com,
i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Description of problem:
there is no Language Selection in GDM. Specially in Live ISO, it can be very
helpful to allow language selection.
Version-Release number of selected component (if applicable):
gdm-2.91.91-1.fc15.x86_64
anaconda-15.20.1-1.fc15
How reproducible:
Everytime
Steps to Reproduce:
1. run gdm from installed system or boot from Live ISO
2.
3.
Actual results:
No language selection in GDM
Expected results:
there can be language selection
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Fedora-i18n-bugs] [Bug 640546] New: [Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used
https://bugzilla.redhat.com/show_bug.cgi?id=640546
Summary: [Indic] Find/Replace Box has problem with halant,
Backspace is not working if halant is used
Product: Fedora
Version: 14
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: gedit
AssignedTo: rstrode(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: rstrode(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Target Release: ---
Description of problem:
While pressing backspace in gedit's Find/find & Replace box and if halant (U+
094D of Hindi), it is not working anyway.
Version-Release number of selected component (if applicable):
gedit-2.30.4-1.fc14.x86_64
How reproducible:
Everytime
Steps to Reproduce:
1. run gedit
2. type or copy paste (क्प)
3. Backspace two times
Actual results:
first backsapace will work, but 2nd will not
Expected results:
with halant (094d), it is should work
Additional info:
1) Delete is working as expected
2) supposed to problem for all Indic locales, which has halant
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Fedora-i18n-bugs] [Bug 635957] New: [qt][Cursoring][Indic] - Composed Character Deletion is wrong with DELETE Button
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [qt][Cursoring][Indic] - Composed Character Deletion is wrong with DELETE Button
https://bugzilla.redhat.com/show_bug.cgi?id=635957
Summary: [qt][Cursoring][Indic] - Composed Character Deletion
is wrong with DELETE Button
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: qt
AssignedTo: than(a)redhat.com
ReportedBy: smaitra(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: rdieter(a)math.unl.edu, than(a)redhat.com,
kevin(a)tigcc.ticalc.org, aalam(a)redhat.com,
itamar(a)ispbrasil.com.br, ltinkl(a)redhat.com,
thomasj(a)fedoraproject.org, jreznik(a)redhat.com,
i18n-bugs(a)lists.fedoraproject.org,
smparrish(a)gmail.com, rnovacek(a)redhat.com
Blocks: 631761,631768
Classification: Fedora
Target Release: ---
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Fedora-i18n-bugs] [Bug 635961] New: [Pango][Cursoring][mr_IN] - Composed Character Deletion is wrong with DELETE Button
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [Pango][Cursoring][mr_IN] - Composed Character Deletion is wrong with DELETE Button
https://bugzilla.redhat.com/show_bug.cgi?id=635961
Summary: [Pango][Cursoring][mr_IN] - Composed Character
Deletion is wrong with DELETE Button
Product: Fedora
Version: 13
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: pango
AssignedTo: behdad(a)fedoraproject.org
ReportedBy: smaitra(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org, aalam(a)redhat.com,
smaitra(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Blocks: 631761,635957
Classification: Fedora
Target Release: ---
Description of problem:
In pango (tested it in gedit and firefox), the deletion with DELETE key, is not
following the rule of deleting entire composed character with a single key
press. It is deleting each of the character in a composed character, one by
one.
Version-Release number of selected component (if applicable):
pango-1.28.0-1.fc13.i686
How reproducible:
Always
Steps to Reproduce:
1. Open gedit or firefox in mr_IN locale
2. Activate ibus with CTRL+SPACE. Select marathi - Inscript
3. Type : kdk (which means consonant KA + Halant + Consonant KA)
4. Position the cursor at the beginning point of the composed character.
5. Now, press DELETE key. (It needs 3 key strokes to delete the whole
character, but it should be done with a single key stroke in fact)
Actual results:
Delete composed character is happening in wrong manner. Actually it is now
following the convention (Rule) of BACKSPACE, when deleting a composed
character comes into picture.
Expected results:
It should delete the whole composed character in one DELETE key stroke when
cursor positions at the start of the composed character.
Additional info:
OS : Fedora 13
Arch : i386
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Fedora-i18n-bugs] [Bug 627127] New: [Indic] Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit)
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [Indic] Rendering of Text broken when Copy from Evince and Paste to Text editor (gedit)
https://bugzilla.redhat.com/show_bug.cgi?id=627127
Summary: [Indic] Rendering of Text broken when Copy from Evince
and Paste to Text editor (gedit)
Product: Fedora
Version: 13
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: evince
AssignedTo: mkasik(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: i18n-bugs(a)lists.fedoraproject.org
CC: mkasik(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Target Release: ---
Created attachment 440846
--> https://bugzilla.redhat.com/attachment.cgi?id=440846
PDF file with Hindi Text
Description of problem:
- Rendering of Text broken when Copy from Evince and Paste to Text editor
(gedit),
Version-Release number of selected component (if applicable):
gedit-2.30.2-1.fc13.x86_64
cairo-1.8.10-1.fc13.x86_64
cairo-1.8.10-1.fc13.i686
pango-1.28.0-1.fc13.x86_64
pango-1.28.0-1.fc13.i686
evince-2.30.3-1.fc13.x86_64
How reproducible:
Everytime
Steps to Reproduce:
1. open attached pdf file
2. try to copy and paste text to any text editor
3. open http://www.bbc.co.uk/hindi/news/2010/08/100825_nuke_bill_govt_vv.shtml
and copy paste data from this to text editor
Actual results:
Rendering is broken (compare with firefox->gedit copy/paste)
Expected results:
it should be same as print or Text in PDF file.
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are on the CC list for the bug.
9 years, 3 months
[Fedora-i18n-bugs] [Bug 1136252] New: PyGTKDeprecationWarning messages on terminal
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1136252
Bug ID: 1136252
Summary: PyGTKDeprecationWarning messages on terminal
Product: Fedora
Version: 21
Component: system-config-language
Assignee: pnemade(a)redhat.com
Reporter: pnemade(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com,
pnemade(a)redhat.com, psatpute(a)redhat.com
Description of problem:
$ system-config-language
/usr/share/system-config-language/language_gui.py:37: PyGTKDeprecationWarning:
Using positional arguments with the GObject constructor has been deprecated.
Please specify keyword(s) for "label" or use a class specific constructor. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
self.title = Gtk.Label(_("Language Selection"))
/usr/share/system-config-language/language_gui.py:38: PyGTKDeprecationWarning:
Using positional arguments with the GObject constructor has been deprecated.
Please specify keyword(s) for "label" or use a class specific constructor. See:
https://wiki.gnome.org/PyGObject/InitializerDeprecations
self.msglable = Gtk.Label(_("Please select the default language for "
Loaded plugins: langpacks
Version-Release number of selected component (if applicable):
system-config-language-2.3.0-1.fc21.noarch
How reproducible:
always
Steps to Reproduce:
1.
2.
3.
Actual results:
PyGTKDeprecationWarning messages on terminal
Expected results:
no PyGTKDeprecationWarning messages
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kHQWyTvRJ8&a=cc_unsubscribe
9 years, 4 months
[Fedora-i18n-bugs] [Bug 1024198] New: No way to change the desktop language in MATE Live
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1024198
Bug ID: 1024198
Summary: No way to change the desktop language in MATE Live
Product: Fedora
Version: 20
Component: LiveCD
Keywords: i18n
Assignee: mclasen(a)redhat.com
Reporter: tagoh(a)redhat.com
CC: i18n-bugs(a)lists.fedoraproject.org
Description of problem:
MATE spin doesn't contain system-config-language nor the ability to change the
language at the display manager unless I'm missing something there. so the user
can't change the language on MATE Live.
Version-Release number of selected component (if applicable):
Fedora-Live-MATE-Compiz-x86_64-20-Beta-TC6.iso
How reproducible:
always
Steps to Reproduce:
1.boot iso
2.
3.
Actual results:
No system-config-language nor language selector at the display manager
Expected results:
should support any way to change the language
Additional info:
Apparently no a kind of "LiveCD - MATE" component in bugzilla. so just filed
this here.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7ZZznpufQh&a=cc_unsubscribe
9 years, 4 months
[Fedora-i18n-bugs] [Bug 923346] New: Symbols incorrectly displayed
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=923346
Bug ID: 923346
Summary: Symbols incorrectly displayed
Product: Fedora
Version: 18
Component: google-croscore-fonts
Severity: high
Priority: unspecified
Assignee: pnemade(a)redhat.com
Reporter: jv+fedora(a)fcelda.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: andreas.bierfert(a)lowlatency.de,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, jreznik(a)redhat.com,
kevin(a)tigcc.ticalc.org, ltinkl(a)redhat.com,
mike(a)cchtml.com, mkasik(a)redhat.com,
pnemade(a)redhat.com, rdieter(a)math.unl.edu,
richard(a)rsk.demon.co.uk, rnovacek(a)redhat.com,
stefan(a)lsd.co.za, than(a)redhat.com, tibbs(a)math.uh.edu
Depends On: 901858
I'm seeing the same problem as described in bug #901858 with
google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch package. Removing the
package solves the problem and math symbols are displayed correctly.
google-croscore-symbolneu-fonts-1.21.0-4.fc18.noarch
okular-4.10.1-1.fc18.x86_64
+++ This bug was initially created as a clone of Bug #901858 +++
Created attachment 683157
microchip pdf showing the fault
Description of problem:
When reading technical pdfs, the wrong symbols are displayed for some math
characters. e.g. pi is displayed as not equal, ohms as a vertical bar, and
micro (mu) is displayed as infinity.
Version-Release number of selected component (if applicable):
okular-4.9.5.-1.fc18
How reproducible:
Displaying a technical pdf such as
http://ww1.microchip.com/downloads/en/AppNotes/00954A.pdf
shows the wrong symbols.
E.G. In figure 1 - the value for C2 is displayed as 470 (inf) F instead of 470
(mu) F
Steps to Reproduce:
1. Display technical pdf
2.
3.
Actual results:
pi is displayed as not equals
ohms as a vertical bar
micro(mu) as infinity
Expected results:
The correct symbols should be displayed
Additional info:
Evince also has this problem, but emacs displays everything correctly.
This happens across a range of pdfs and I think is a serious bug than needs
fixing as soon as possible,. It reflects badly on fedora if we cannot display
technical specifications properly.
--- Additional comment from Kevin Kofler on 2013-01-19 12:47:09 EST ---
> Evince also has this problem
Reassigning to poppler, which is the common library used by both.
What I see is that this PDF does not embed its fonts, which means you get
whatever fonts are installed on the system. In this case, Symbol is mapped to
wine-symbol-fonts. So I'm not sure whether poppler or the font is doing the
wrong thing there.
And by the way, the PDF is bad because it uses a font outside of the PostScript
standard (Symbol) and doesn't embed it. A portable PDF MUST embed all the
non-PostScript fonts it uses.
--- Additional comment from Richard Kennedy on 2013-02-28 07:57:45 EST ---
Just a quick update.
The new embedded pdf reader in Firefox 19 displays these files correctly too.
Well, the pdf may not be correct but it was created by adobe software & there
are lots of them out in the wild, so we should do something to fix it.
Can I change the default font mapping for popper to something else ? If so how
do I go about that?
--- Additional comment from Kevin Kofler on 2013-02-28 19:00:01 EST ---
As I said, it's a bug in either poppler or wine-symbol-fonts (or both).
Unfortunately, the poppler maintainer hasn't answered so far.
--- Additional comment from Marek Kašík on 2013-03-01 07:05:38 EST ---
Hi,
this is a bug in wine-symbol-fonts package. The symbol.ttf font has wrong
mapping.
For additional info see upstream bug
http://bugs.winehq.org/show_bug.cgi?id=24099.
I'm reassigning this to wine.
Regards
Marek
--- Additional comment from Jason Tibbitts on 2013-03-01 14:45:34 EST ---
Wow, it's great news that this the cause is known, because I've been struggling
with this for some time. Unfortunately upstream bug report has been there for
quite some time with no progress, so I'm not sure what chance we have of
getting this fixed. What would break by removing this font? Can it be removed
from the dependency list of the wine-fonts metapackage?
--- Additional comment from Kevin Kofler on 2013-03-01 17:53:16 EST ---
Would that really fix the issue? I don't think the symbols can be properly
displayed if the font is entirely missing. I suspect there's no way around
fixing the font.
--- Additional comment from Richard Kennedy on 2013-03-02 11:50:34 EST ---
I've just fixed the font following the steps in the wine bug 24099 and it
works.
I only run one wine app, ltspice, and it still works after the fix, so it's all
looking good.
Both firefox & emacs can display these characters properly so they must be
using some other font, but I don't know how to find out which one. But if we
could find out can we swap the mapping to that?
--- Additional comment from Richard Kennedy on 2013-03-02 13:29:50 EST ---
Having thought about this some more, I think that is more likely that the bug
really is that poppler isn't handling unicode characters properly.
I cut & pasted the failing mu character from evince into emacs, and it says
it's unicode 0x3BC. So it seems that poppler tries to use the symbol font and
0x3BC
is something different in there because it's broken too.
emacs and firefox somehow resolve the unicode character correctly and don't end
up in the symbol font, but I haven't found out which font they do use.
I didn't realise all of this stuff was so involved and complex. At least fixing
up the font is a temporary fix.
--- Additional comment from Kevin Kofler on 2013-03-02 17:58:39 EST ---
Maybe poppler shouldn't be looking up "Symbol" in fontconfig at all, but handle
the Symbol font specially? The Window$ Symbol TTF font which WINE's font tries
to emulate is a hack which predates Unicode and maps Greek letters and other
symbol characters to plain 8-bit characters (0-255). Somebody should probably
test what happens when you use the original M$ Symbol.ttf. If it has the same
issue, it's not WINE's fault.
--- Additional comment from Richard Kennedy on 2013-03-04 12:44:39 EST ---
Just a couple of notes :-
* The poppler version here is 0.20.2 which was released on Tue July 10, 2012,
and
the latest is 0.22.1 which contains quite a number of bug fixes.
* I've reset my machine to the default state and if I run pdftohtml on this
file
the correct characters are generated in the html. (pdftohtml is a poppler
tool).
* Libre Office also can display these files correctly.
Is there any way to get poppler to use the opensymobol font to resolve these
symbols? AFAICT opensymbol contains all of the correct unicode so might make a
good replacement and it's already installed.
--- Additional comment from Marek Kašík on 2013-03-05 07:26:52 EST ---
Created attachment 705385
blacklist wine font Symbol
(In reply to comment #10)
> Just a couple of notes :-
>
> * The poppler version here is 0.20.2 which was released on Tue July 10,
> 2012, and
> the latest is 0.22.1 which contains quite a number of bug fixes.
The poppler-0.22.1 doesn't fix this.
> * I've reset my machine to the default state and if I run pdftohtml on this
> file
> the correct characters are generated in the html. (pdftohtml is a poppler
> tool).
It generates correct html because the codes for those characters are correct in
the pdf.
> * Libre Office also can display these files correctly.
Do you mean the html or the pdf? Libre Office displays me the same characters
as poppler when importing the pdf.
> Is there any way to get poppler to use the opensymobol font to resolve these
> symbols? AFAICT opensymbol contains all of the correct unicode so might make
> a good replacement and it's already installed.
Place the attached file to ~/.config/fontconfig/fonts.conf. This will blacklist
the font for all applications which use fontconfig (useful when the
wine-symbol-fonts is a dependency of a package which you don't want to remove).
I've tried to view a file with the character for the micro sign (UTF-8 code
0xC2B5) in notepad which is part of wine-common. After switching the font to
"Symbol", it showed me the incorrect symbol. I guess that there is really
something wrong with the font.
Regards
Marek
--- Additional comment from Kevin Kofler on 2013-03-05 10:00:50 EST ---
The problem is that the Symbol font was designed in a way that the 'm'
character is displayed as 'µ', and 'µ' is not mapped to anything. In fact,
Symbol was the way to get those special characters in old software which didn't
support Unicode. I don't know whether it's possible to fix this issue without
breaking that old software when people try to run it under WINE. I hope it's
possible, but I'm not sure. The WINE upstream bug report has a proposed fix,
but I don't know whether that fix doesn't break the non-Unicode apps.
--- Additional comment from Andreas Bierfert on 2013-03-05 14:55:02 EST ---
Well as a workaround we could confine wine symbol to wine for now (like with
tahoma). This would reduce the problem to wine applications.
Before resorting to this I will investigate a bit...
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=mExkG0NduF&a=cc_unsubscribe
9 years, 4 months
[Fedora-i18n-bugs] [Bug 734751] New: RFE: improve UI
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: RFE: improve UI
https://bugzilla.redhat.com/show_bug.cgi?id=734751
Summary: RFE: improve UI
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Keywords: FutureFeature
Severity: unspecified
Priority: unspecified
Component: iok
AssignedTo: pnemade(a)redhat.com
ReportedBy: tagoh(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: pnemade(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Story Points: ---
Type: ---
Description of problem:
I have some thoughts on improving UI for iok, particularly for the use case on
non-Indic language.
1) Get rid of "English" entry from the language list.
That is meaningless to keep it there since "to English" button is available.
2) should keep the same state to the initial state after clicking "to English"
button.
I think the initial state would be natural. I mean selecting the language
from ASCII layout (English mode) since the neutral position is ASCII layout on
other IM. however once selecting the language from the list and switch back to
English mode with "to English" button, iok masks the language list. one needs
to switch with "To <language" button to choose other language from the list.
this behavior isn't consistent to the initial state and other IM. there are IM
that supports to switch multiple IME regardless of current state though, if you
want to provide such features, you should simply stop masking the language
list.
3) maybe "to ASCII" is better than "to English"?
I like to see the icon to indicate the state of "on" and "off" with the icon
though, if you want to keep the string, guess that would be better using
"ASCII" instead of "English".
4) selected the language from the list should keeps it default in next time
5) entries in the language list should be translatable
Since it's hidden when running iok on any Indic locale, that should appears
in the native language on current desktop. that would be helpful for those who
wants to learn Indic but running iok on their locale.
6) simplify the language list like the IME list on ibus
there are too many entries on the language list. that would be nice to
simplify like ibus does.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 4 months