https://bugzilla.redhat.com/show_bug.cgi?id=1007493
Bug ID: 1007493
Summary: shipped fonts.alias includes references to missing
sazanami-times font
Product: Fedora
Version: rawhide
Component: sazanami-fonts
Assignee: tagoh(a)redhat.com
Reporter: leftmostcat(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, tagoh(a)redhat.com
fonts.alias in the sazanami package is reporting the existence of a
sazanami-times font face to Xorg which does not appear to exist. This is
causing problems in other packages.
--
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=fuECin9gKM&a=cc_unsubscribe
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: chewing cannot preview chinese characters in activities search box
https://bugzilla.redhat.com/show_bug.cgi?id=754932
Summary: chewing cannot preview chinese characters in
activities search box
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: medium
Priority: unspecified
Component: ibus-chewing
AssignedTo: dchen(a)redhat.com
ReportedBy: johnxu(a)linpus.com
QAContact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com
Classification: Fedora
Story Points: ---
Type: ---
Description of problem:
input chinese to activities search box, cannot get the preview characters.
Version-Release number of selected component (if applicable):
ibus-1.3.9.2-3
How reproducible:
Always
Steps to Reproduce:
1.focus in activities search box
2.select ibus-chewing
3.enter "tk"+space
Actual results:
nothing display in search box
Expected results:
preview character "車" in search box
Additional info:
Does ibus-chewing can provide a candidate window like ibus-pinyin?
--
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=1009350
Bug ID: 1009350
Summary: generated output looks not correct
Product: Fedora
Version: 19
Component: ttmkfdir
Keywords: i18n
Assignee: psatpute(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Blocks: 1007493
Description of problem:
This is output with sazanami fonts:
sazanami-gothic.ttf -misc-Sazanami Gothic-medium-r-normal--0-0-0-0-c-0-ascii-0
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-iso10646-1
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-1
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-15
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-iso8859-9
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1983-0
sazanami-gothic.ttf -misc-Sazanami
Gothic-medium-r-normal--0-0-0-0-c-0-jisx0208.1990-0
Apparently there are no jisx0201.1976-0 for that.
Version-Release number of selected component (if applicable):
ttmkfdir-3.0.9-39.fc19.x86_64
How reproducible:
always
Steps to Reproduce:
1.ttmkfdir -d /path/to/sazanami/font
2.see the generated fonts.scale
3.
Actual results:
no jisx0201.1976-0
Expected results:
should be there
Additional info:
http://en.wikipedia.org/wiki/JIS_X_0201 for more details of JIS X 0201
1976 is a revision number for this spec.
--
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=z7O9EydZoW&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=843331
Bug ID: 843331
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: rawhide
Priority: unspecified
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com
Assignee: psatpute(a)redhat.com
Summary: [ta_IN] Please add glyphs for minority orthographies
in Tamil
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-tamil-fonts
Product: Fedora
Created attachment 600434
--> https://bugzilla.redhat.com/attachment.cgi?id=600434&action=edit
Glyphs required for minority orthographies in Tamil
While the Tamil script is mainly used for writing Tamil language text, it is
also attested to be used for other language text such as Sanskrit, Saurashtra,
Hindi, Marathi, Telugu and Kannada in the form of transliteration.
For these minority orthography usecases, some characters from script-neutral
blocks are required:
1) The superscript digits ¹²³⁴ would be used for representing the varga
consonants (actually ¹ is only used very rarely). The Unicode chapter on Tamil
script documents this and recommends the characters (0xb9) 0xb2 0xb3 0x2074.
2) Not only the superscript digits but their corresponding subscript digits
₁₂₃₄ (0x2081-0x2084) are also attested as a stylistic variant choice.
3) The modifier letter apostrophe 02BC ʼ is also seen.
4) Further, sometimes the candrabindu is also seen for nasality. Since there is
no Tamil candrabindu character, the generic candrabindu ◌̐ at 0310 can be
used.
5) The visarga is commonly seen but the Tamil visarga code point 0B83 is mapped
to the Tamil special letter aytam ஃ (which has three dots against the visarga's
two dots), so we will have to place the two-dot visarga in the PUA. (Not ideal
I know, but it is unlikely to encode a Tamil-specific two-dot visarga. It is
not possible to use the Devanagari visarga codepoint 0903 since rendering
engines will produce dotted circles as it is not correct to combine Devanagari
codepoints with Tamil codepoints.)
Attestations for these usages and required glyphs are attached. Please add them
with the appropriate script-neutral codepoints shown in the patch TTF so Lohit
Tamil (and Lohit Tamil Classical) is also useful for these minority
orthographies. BTW it would be good font design policy to make the modifier
apostrophe a composite glyph of the regular apostrophe and subscript digits as
composites of superscript digits.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1078661
Bug ID: 1078661
Summary: Deprecate the usage of U+0BB8 U+0BCD U+0BB0 U+0BC0
for SRII per latest unicode standard
Product: Fedora
Version: rawhide
Component: lohit-tamil-fonts
Severity: medium
Assignee: psatpute(a)redhat.com
Reporter: srik.lak+public(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
Description of problem:
Complex glyph SRI was changed from U+0BB8 U+0BCD U+0BB0 U+0BC0 to U+0BB6
U+0BCD U+0BB0 U+0BC0 in Unicode 4.1. Lohit-Tamil displays the complex glyph for
both forms for backward compatibility. However this also prevents migration to
latest standard as some input tools too offer same functionality leading to
more content created with U+0BB8 U+0BCD U+0BB0 U+0BC0 as SRI which increases
the need for backward compatibility. To break this vicious cycle, I propose
U+0BB8 U+0BCD U+0BB0 U+0BC0 should not be substituted with complex glyph SRI
and should be displayed normally. Apple / iOS fonts already do this complying
with latest unicode standard. Failing to move to single consistent
representation in line with latest unicode leads to fragmentation within
unicode text, a greater cause for worry than backward compatibility.
I understand the larger problem of standardization cannot happen only by
changing this font, but its a start and Lohit being the only maintained free
Tamil font, can help in the process.
Version-Release number of selected component (if applicable):
2.5.3
How reproducible:
Always
Steps to Reproduce:
1. ஸ்ரீ (U+0BB8 U+0BCD U+0BB0 U+0BC0) should be displayed as ஸ்(U+0BB8 U+0BCD)
ரீ(U+0BB0 U+0BC0) without a space in middle and not compounded form.
Actual results:
U+0BB8 U+0BCD U+0BB0 U+0BC0 giving complex glyph SRI
Expected results:
U+0BB8 U+0BCD U+0BB0 U+0BC0 should not give complex glyph SRI, should give
U+0BB8 U+0BCD and U+0BB0 U+0BC0 seperately.
Change Required:
The line
Ligature2: "'abvs' Above Base Substitutions in Tamil lookup 0 subtable"
u0BB8_u0BCD.half u0BB0 u0BC0
in Lohit-Tamil.sfd should be removed.
Additional info:
See also bug 450699
--
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=D75hFGPezF&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1024071
Bug ID: 1024071
Summary: ibus-m17n is enabled in the password entry field of
the lock screen
Product: Fedora
Version: 20
Component: ibus-m17n
Assignee: dueno(a)redhat.com
Reporter: mfabian(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com
Created attachment 816871
--> https://bugzilla.redhat.com/attachment.cgi?id=816871&action=edit
ibus-m17n-latn-post-enabled-in-password-entry-field-of-lockscreen.png
Fedora 20 Beta TC6.
See screen shot.
Apparently, ibus-m17n does not check for IBUS_INPUT_PURPOSE_PASSWORD
yet, therefore it is enabled in the password field.
ibus-anthy, ibus-libpinyin, and ibus-typing-booster do not show this
problem (they already check input purpose).
--
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=w63kBcccZE&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=915448
Bug ID: 915448
Summary: Spell check problem (UTF8 conversion?) with Hunspell
Product: Fedora
Version: 18
Component: emacs
Severity: unspecified
Priority: unspecified
Reporter: igor.redhat(a)gmail.com
+++ This bug was initially created as a clone of Bug #725235 +++
Created attachment 514921
Sample text with accents (md5sum f91f52b0ae84fd91aa25e0d671228a23)
Description of problem:
When using emacs / hunspell to spell-check a UTF-8 encoded text file, emacs
chokes on some accented letters, with the error message:
Ispell error: UTF-8 encoding error. Missing continuation byte in 0. character
position:
Spell-checking testtext.txt using hunspell with default dictionary...done
ispell-process-line: Wrong type argument: number-or-marker-p, nil
Version-Release number of selected component (if applicable):
emacs-23.2-19.fc15.i686
using
hunspell-1.2.15-2.fc15.i686
hunspell-en-0.20110112-4.fc15.noarch
How reproducible:
Always on my netbook with Fedora 15 for i686.
Steps to Reproduce:
1. Open a text file with accented characters, e.g. the attached test case.
2. Start spell-check in emacs (after making sure that aspell is not installed,
so that emacs will use hunspell.)
3.
Actual results:
Error message as above.
Expected results:
Correct spell-checking session...
Additional info:
This does not happen with aspell.
It also does not happen when spell-checking files using hunspell on the command
line.
For some other files, the error message was:
"this UTF-8 encoding can't convert to UTF-16"
Using "enter debugger on error" on the text file, the following appears in
*Backtrace* (with byte code removed):
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
ispell-parse-output(#("ël!" 0 3 (charset iso-8859-1)) nil 0)
ispell-process-line("^Titre: noël!\n" nil)
byte-code("....310\311!\210)\312\313....")
ispell-region(1 38)
ispell-buffer()
call-interactively(ispell-buffer nil nil)
--- Additional comment from Akira TAGOH on 2012-06-29 07:00:33 EDT ---
ispell.el has the code to find the spell checker program out though, it doesn't
update ispell-dictionary-base-alist according to the result. it should be
optimized against it.
Here is what my .emacs has and I want English spell checker only:
(setq ispell-dictionary-base-alist '((nil
"[[:alpha:]]" "[^[:alpha:]]" "[']"
nil ("-d" "en_US") nil utf-8)))
(eval-after-load "ispell"
(progn
(setq ispell-extra-args '("-a" "-i" "utf-8")
ispell-silently-savep t)))
It work well here.
--- Additional comment from Fedora End Of Life on 2013-01-16 09:39:38 EST ---
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
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 prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 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 to click on
"Clone This Bug" and open it against that version of Fedora.
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.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
--- Additional comment from Fedora End Of Life on 2013-02-13 10:55:37 EST ---
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.
Thank you for reporting this bug and we are sorry it could not be fixed.
--
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=ubqA30ShKa&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=880494
Bug ID: 880494
Summary: French Keyboard layout not following PC105 (physically
same as USA English), and Cannot allocate Eurosymbol
as altchar-E or altchar-5
Product: Fedora
Version: 18
Component: xkeyboard-config
Severity: low
Priority: unspecified
Reporter: lsatenstein(a)yahoo.com
Description of problem:
There is an annaconda problem, and a keyboard layout definition problem and a
physical keyboard layout problem.
Version-Release number of selected component (if applicable):
Fedora 18 RC1 32bit
How reproducible:
F18 RC1 is being installed with default as English language. But I need the
Canadian French Keyboard, as I write both English and French
I added the Canadian French keyboard and placed it first in the list. Anaconda
continues to ignore the CF keyboard mapping. Only way to force a switch from
the US default was is to delete the USA keyboard, which activates the Cdn
French version and then i added back the USA English.
The USA English physical layout is correct. The Canadian French Keyboard must
look like the USA English (PC105 layout). Missing is what configuration we
could do in the past (F16,F17), which was to allow one to assign the Euro
symbol to the alt-char E, or alt-char 5
So, Anaconda needs some correction to fix what I described, and the keyboard
selection physical layout needs to match the physical layout of the USA English
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1074489
Bug ID: 1074489
Summary: outdated ubin_table in charset.c
Product: Fedora
Version: 20
Component: less
Keywords: i18n
Assignee: jmlich(a)redhat.com
Reporter: tagoh(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, jmlich(a)redhat.com
Created attachment 872630
--> https://bugzilla.redhat.com/attachment.cgi?id=872630&action=edit
proposed patch
Description of problem:
less considers the characters in the range between U+20B6 and U+20BA as the
"Not Assigned" and show with $LESSUTFBINFMT. but those were assigned in Unicode
5.2, 6.0 and 6.2.
Version-Release number of selected component (if applicable):
less-458-6.fc20
How reproducible:
always
Steps to Reproduce:
1.echo $'\u20ba' | less
2.
3.
Actual results:
<U+20BA>
Expected results:
₺
Additional info:
You can see more details what they are by gucharmap say.
--
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=HlfCHNRzDF&a=cc_unsubscribe
https://bugzilla.redhat.com/show_bug.cgi?id=1084743
Bug ID: 1084743
Summary: [abrt] ibus: _g_log_abort(): ibus-daemon killed by
SIGABRT
Product: Fedora
Version: 20
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: mothlight(a)fastmail.fm
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Version-Release number of selected component:
ibus-1.5.6-1.fc20
Additional info:
reporter: libreport-2.2.0
backtrace_rating: 4
cmdline: /usr/bin/ibus-daemon -r --xim
crash_function: _g_log_abort
executable: /usr/bin/ibus-daemon
kernel: 3.13.4-200.fc20.x86_64
runlevel: N 3
type: CCpp
uid: 500
Truncated backtrace:
Thread no. 1 (10 frames)
#2 _g_log_abort at gmessages.c:255
#5 bus_dbus_impl_connection_filter_cb at dbusimpl.c:1473
#6 on_worker_message_received at gdbusconnection.c:2328
#7 _g_dbus_worker_emit_message_received at gdbusprivate.c:493
#8 _g_dbus_worker_queue_or_deliver_received_message at gdbusprivate.c:521
#9 _g_dbus_worker_do_read_cb at gdbusprivate.c:805
#10 g_simple_async_result_complete at gsimpleasyncresult.c:777
#11 complete_in_idle_cb at gsimpleasyncresult.c:789
#16 gdbus_shared_thread_func at gdbusprivate.c:278
#17 g_thread_proxy at gthread.c:798
--
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=3RGSO4AjOo&a=cc_unsubscribe