Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Commit Hangul character with space key -> Move the character.
https://bugzilla.redhat.com/show_bug.cgi?id=675503
Summary: Commit Hangul character with space key -> Move the
character.
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Linux
Status: NEW
Severity: high
Priority: unspecified
Component: ibus
AssignedTo: tfujiwar(a)redhat.com
ReportedBy: sangu.fedora(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tfujiwar(a)redhat.com,
i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com
Classification: Fedora
Description of problem:
Commit Hangul character with space key -> Move the character.
Version-Release number of selected component (if applicable):
1.3.99.20110127-1.fc15.x86_64
How reproducible:
always
Steps to Reproduce:
1. input with hangul input method
2. 가가 (rkrk)
3. click space key
Actual results:
가 가
Expected results:
가가
Additional info:
ibus-hangul-1.3.0.20100329-4.fc15.x86_64
glib2-2.27.93-1.fc15.x86_64
gtk2-2.24.0-1.fc15.x86_64
gtk3-2.99.3-1.fc15.x86_64
--
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.
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Proper Bold for Lohit Devanagari
https://bugzilla.redhat.com/show_bug.cgi?id=648350
Summary: Proper Bold for Lohit Devanagari
Product: Fedora
Version: rawhide
Platform: All
OS/Version: All
Status: NEW
Severity: medium
Priority: low
Component: lohit-devanagari-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: ujjwol(a)fedoraproject.org
QAContact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Created attachment 456789
--> https://bugzilla.redhat.com/attachment.cgi?id=456789
Picture showing the bold and regular typeface
Description of problem:
The existing font provided Lohit Devangari only contains the regular version.
It does not contain the bold version. When the computer generates bold using
the regular font, and the results are ugly. The siro-rekha is broken and many
other stuffs are also broken.
Version-Release number of selected component (if applicable):
How reproducible:
Exactly reproducible
Steps to Reproduce:
1.See any hindi/nepali/marathi/sanskrit pages in firefox with bold text
2. type devanagari text in openoffice and bold it
Actual results:
The a broken lohit devanagari font is displayed.
Expected results:
A well maintained bold should be shown.
Additional info:
The typographic value is lost when bold is used though it is still readable.
--
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1016989
Bug ID: 1016989
Summary: [ml_IN] non-standard sequence sequence for stacked
chillu-N and RRA in Lohit Malayalam font should be
removed
Product: Fedora
Version: rawhide
Component: lohit-malayalam-fonts
Assignee: psatpute(a)redhat.com
Reporter: samjnaa(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
This is related to bug #1016984 which I reported just now.
As per TUS 6.2 chapter 9.9 p 321 (p 351 of PDF) the correct sequence to get the
display of stacked chillu-N on top of RRA in Malayalam is: CHILLU N + VIRAMA +
RRA. That is: ൻ്റ = 0d7b 0d4d 0d31. However, currently Lohit Malayalam font
does not support this sequence. In bug #1016984 I have requested to add it.
Apart from that, note that currently the sequence being used to display stacked
chillu-N on top of RRA in Lohit font is ന്റ = 0d28 0d4d 0d31. This is
non-standard. It is inadvisable to retain this sequence as having two
canonically non-equivalent sequences display the same is a security issue of
confusability.
My request from the POV of being standard-compliant would be to remove this
sequence.
However I am sure (based on personal email communication) there will be
objection from people such as Santosh Thottingal since they do not agree with
the standard on this matter. They maintain that NA + VIRAMA + RRA is the
correct sequence to get this display.
I have told them that if they disagree with the standard then they should
discuss the matter on the Unicode and try to make the Unicode Technical
Committee accept their view. Otherwise such sequences will just be
standards-non-compliant and the existing diversified situation will only be
aggravated.
Certainly the current standard-prescribed sequence should be included to be
standards compliant. For that I have already filed the separate bug. For 100%
compliance the old non-standard should be removed. To track that I am filing
this bug now.
In the face of community objection, it is up to the project maintainer to
decide about this.
Version-Release number of selected component (if applicable):
2.5.4
--
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=4mzVmSKdWJ&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1040337
Bug ID: 1040337
Summary: [or_IN][texlive] - Change language name from "Oriya"
to "Odia"
Product: Fedora
Version: rawhide
Component: texlive
Keywords: i18n
Severity: low
Priority: medium
Assignee: novyjindrich(a)gmail.com
Reporter: smaitra(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
novyjindrich(a)gmail.com, pertusus(a)free.fr,
smaitra(a)redhat.com, than(a)redhat.com
Description of problem:
Upstream bug reference : https://sourceware.org/bugzilla/show_bug.cgi?id=15601
Preface : As per the Govt of India record, the State name of Orissa has been
replaced with Odisha (hopefully I am correct with its spelling) and the
language of Odisha State which was Oriya earlier, has been replaced with Odia.
Please change the word "Oriya" occurrences to "Odia" in SPEC file.
Version-Release number of selected component (if applicable):
texlive-hyphen-indic-svn25990.0-3.fc21
How reproducible: N/A
Steps to Reproduce:N/A
1.
2.
3.
Actual results:
Presently the word "Oriya" is mentioned in the SPEC file.
Expected results:
Please replace the word "Oriya" with the word "Odia" in the SPEC File for all
the occurrences.
Additional info:
References:
http://orissamatters.com/2011/11/07/orissa-became-odisha/http://www.ndtv.com/article/india/parliament-passes-bill-to-change-orissa-s…http://orissa.gov.in/e-magazine/Orissareview/2011/Nov/engpdf/9-17.pdf
--
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=HwHbDVF15X&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=985343
Bug ID: 985343
Summary: After telugu input .(full stop) is rendering as square
box in lokalize editor
Product: Fedora
Version: 19
Component: lohit-telugu-fonts
Severity: unspecified
Priority: unspecified
Assignee: psatpute(a)redhat.com
Reporter: kkrothap(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Created attachment 774715
--> https://bugzilla.redhat.com/attachment.cgi?id=774715&action=edit
Example screen shot regarding the problem.
Description of problem:
While using lokalize as translation editor, after telugu input if i type .(full
stop) it is rendering as square box.
Version-Release number of selected component (if applicable):
lohit-telugu-fonts-2.5.3-2.fc19.noarch
kdesdk-lokalize-4.10.5-1.fc19.x86_64
How reproducible:
Every time
Steps to Reproduce:
1.Open lokalize.
2.Input some telugu text.
3.Type . after telugu text.
Actual results:
. rendering as square box
Expected results:
Should render as it should be.
Additional info:
Working fine with pothana font.
--
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=NeVSFyXCJw&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1108612
Bug ID: 1108612
Summary: CVE-2014-3980 libfep: local privilege escalation via
UNIX domain sockets in the abstract namespace
Product: Security Response
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: vkaigoro(a)redhat.com
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
It was discovered that libfep uses UNIX domain sockets in the abstract
namespace in an insecure way. As a result, unprivileged local users
were able to inject commands into running fep sessions of other users.
The upstream fix simply removes abstract namespace support, using a
restricted directory to host the UNIX domain socket instead:
https://github.com/ueno/libfep/commit/293d9d3f
Abstract namespace support was introduced in this commit:
https://github.com/ueno/libfep/commit/5a170323
This means that versions from 0.0.5 to 0.0.9 (inclusive) are vulnerable,
and 0.1.0 has the fix.
External references:
http://www.openwall.com/lists/oss-security/2014/06/05/16http://www.securityfocus.com/bid/67903
--
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=ZaCbDdpjD1&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1028911
Bug ID: 1028911
Summary: [zh_TW]'Chinese<->English' switch does not work when
clicking on the Chewing menu list.
Product: Fedora
Version: 20
Component: ibus-libpinyin
Severity: high
Assignee: pwu(a)redhat.com
Reporter: lijli(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com
Depends On: 1028905
+++ This bug was initially created as a clone of Bug #1028905 +++
Description of problem:
'Chinese<->English' switch does not work when clicking on the Intellignet
Pinyin menu list.
Version-Release number of selected component (if applicable):
ibs-chewing-1.4.3-4.fc20.x86_64
libchewing-0.3.4-4.fc20.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Install latest Fedora20 tc6 build.
2. Add an input source which has (Intelligent Pinyin) in the name.
3. Click on the Chewing menu on the top right of desktop.
4. Click on Chines/English (中CN/英EN, 中/英)from the list to switch the input of
'Chinese-English'.
Actual results:
'Chinese<->English' switch does not work when clicking on the Chewing menu
list.
Expected results:
It should auto switch for 中CN/英EN, 中/英.
Additional info:
Please see the attached screenshot.
--- Additional comment from Lijun Li on 2013-11-11 03:07:34 EST ---
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1028905
[Bug 1028905] [zh_CN]'Chinese<->English' switch does not work when clicking
on the Intellignet Pinyin menu list.
--
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=mXuMqdUFbL&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1089467
Bug ID: 1089467
Summary: [abrt] ibus-table:
table.py:798:update_candidates:IndexError: pop from
empty list
Product: Fedora
Version: 20
Component: ibus-table
Assignee: mfabian(a)redhat.com
Reporter: gzjboy(a)163.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
kent.neo(a)gmail.com, me(a)kaio.net, mfabian(a)redhat.com,
pwu(a)redhat.com, shawn.p.huang(a)gmail.com
Version-Release number of selected component:
ibus-table-1.5.0.20140312-2.fc20
Additional info:
reporter: libreport-2.2.1
cmdline: /usr/bin/python3 /usr/share/ibus-table/engine/main.py --ibus
executable: /usr/share/ibus-table/engine/main.py
kernel: 3.13.10-200.fc20.x86_64
runlevel: N 5
type: Python3
uid: 1000
Truncated backtrace:
table.py:798:update_candidates:IndexError: pop from empty list
Traceback (most recent call last):
File "/usr/share/ibus-table/engine/table.py", line 1610, in
do_process_key_event
result = self._process_key_event (key)
File "/usr/share/ibus-table/engine/table.py", line 1632, in
_process_key_event
return self._table_mode_process_key_event (key)
File "/usr/share/ibus-table/engine/table.py", line 1867, in
_table_mode_process_key_event
res = self._editor.add_input ( keychar )
File "/usr/share/ibus-table/engine/table.py", line 407, in add_input
res = self.update_candidates ()
File "/usr/share/ibus-table/engine/table.py", line 798, in update_candidates
self._tabkey_list.pop()
IndexError: pop from empty list
Local variables in innermost frame:
self: <table.editor object at 0x7f9de0376710>
only_one_last: False
--
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=uTlBnGIXuQ&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=984230
Bug ID: 984230
Summary: Broken aliasing on small sizes since version 2.00
Product: Fedora
Version: 18
Component: liberation-fonts
Severity: medium
Priority: unspecified
Assignee: psatpute(a)redhat.com
Reporter: gitne(a)excite.co.jp
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
The pixel aliasing of glyphs, especially vertical lines/parts is broken since
version 2.00 on Windows (renderer). This applies to all Liberation Font types
when ClearType is off, i.e. with gray-scale anti-aliasing only. Version 2.00
has incurred aliasing for all font sizes. Version 2.00.1 fixed this by
disabling anti-aliasing for sizes < 14pt. Yet, vertical lines/parts and some
transitions from curves to lines are still rendered incorrectly or with
artifacts.
This may also apply to Fedora GNOME desktops, but it has been observed on
Windows first.
Although, I am not a font design specialist, I suppose that this problem exists
because version 2.00 is based on Google Crosscore fonts and hinting information
for small font sizes is missing.
This is a show stopper for software rendering Libration Fonts on pixel based
digital displays. Software packages like LibréOffice are also negatively
affected by this issue (although on displays only). Please resolve this issue
or revert verion 2.00 and later to beta status.
How to reproduce:
Windows XP/2003
Compare Liberation Fonts version 1.07 to version 2.00.1 for small font sizes <
14pt.
Windows Vista and later
Disable ClearType
Compare Liberation Fonts version 1.07 to version 2.00.1 for small font sizes <
14pt. Version 1.07 has been correctly hinted, hence is perfectly pixel aligned.
--
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=MocNtqGafn&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=953703
Bug ID: 953703
Summary: 3 cyrillic fonts are missing
Product: Fedora
Version: rawhide
Component: liberation-fonts
Severity: high
Priority: unspecified
Assignee: psatpute(a)redhat.com
Reporter: translatorky(a)lavabit.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com
Category: ---
Description of problem: Please add 3 missing cyrillic fonts
U+04A2 Ң
U+04A3 ң
U+04E8 Ө
U+04E9 ө
U+04AE Ү
U+04AF ү
Version-Release number of selected component (if applicable): Minetest game
using liberationmono and liberationsans fonts, in version 0.4.6 was added
kyrgyz language translations
How reproducible: Open Minetest 0.4.6 with kyrgyz language locale
Steps to Reproduce:
1. Go to Minetest.net and download 0.4.6 version
2. Open Minetest with kyrgyz language locale
3. 3 cyrillic fonts are invisible
Actual results:
Expected results:
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=ueHlHhfaur&a=cc_unsubscribe