[Fedora-i18n-bugs] [Bug 1580458] New: [ta_IN] Error in latest Tamil ttf
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1580458
Bug ID: 1580458
Summary: [ta_IN] Error in latest Tamil ttf
Product: Fedora
Version: rawhide
Component: lohit-tamil-fonts
Severity: high
Assignee: psatpute(a)redhat.com
Reporter: nsesha92(a)yahoo.co.in
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 1439625
--> https://bugzilla.redhat.com/attachment.cgi?id=1439625&action=edit
Error screen shot jpeg
Description of problem:
Hi,
1. Latest ttf-tar says version 2.91.3, but when installed it shows as 2.91.1
2. Glyph issue with 'ra', 'na' and its i, ii, u, uu .. series.
3. shrii is missing, should be next to kshii per 2.5.3
Screen shot attached.
Wram regards
Seshadri
Version-Release number of selected component (if applicable):
2.91.3 & 2.91.1
How reproducible:
Screen shot attached.
Steps to Reproduce:
1. See in Windows Character Map
2.
3.
Actual results:
Expected results:
Additional info: I am trying my luck with FontForge to correct these errors.
Will try to get back in few days.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 8 months
[Fedora-i18n-bugs] [Bug 1565499] New: Ibus emoji dialog closes after selecting one emoji.
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1565499
Bug ID: 1565499
Summary: Ibus emoji dialog closes after selecting one emoji.
Product: Fedora
Version: 28
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: poyadav(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Description of problem:
ibus emoji dialog box closes after selecting one emoji only, need to launch it
again if we need to select another emoji.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce:
1. Launch ibus emoji dialog using ibus emoji or ctrl-shift-e.
2. Search for a emoji and select it.
3. After selecting the emoji, dialog box closes
Actual results:
Dialog box closes after selecting one emoji
Expected results:
Additional info:
Ibus emoji should box should remain open if we haven't closed it, so that we
don't have to open it again if we want to select more than one emoji.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 8 months
[Fedora-i18n-bugs] [Bug 1569943] New: upgrading from Liberation 1 to 2 in a desktop session can affect rendering of text
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
Bug ID: 1569943
Summary: upgrading from Liberation 1 to 2 in a desktop session
can affect rendering of text
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alexl(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, mbarnes(a)fastmail.com,
mclasen(a)redhat.com, petersen(a)redhat.com,
psatpute(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
Description of problem:
The Liberation 1 and 2 fonts may be binary incompatible
in the sense that upgrading a live desktop from Liberation 1 to 2
seemed to corrupt some characters for me in Firefox (with Ariel text in
Google Docs for the default unordered list mark symbols).
Version-Release number of selected component (if applicable):
liberation-fonts-2.00.1
Actual results:
'·' -> '>'
'⃝' -> '<'
for example
Expected results:
Not change of glyphs.
Additional info:
I suspect this might be due to caching of the old font's tables in memory.
It would be better if the tables were more compatible I suppose.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 8 months
[Fedora-i18n-bugs] [Bug 1382982] New: Fedora iBus typing language detector breaks events call stack of web pages
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1382982
Bug ID: 1382982
Summary: Fedora iBus typing language detector breaks events
call stack of web pages
Product: Fedora
Version: 24
Component: ibus
Severity: urgent
Assignee: tfujiwar(a)redhat.com
Reporter: danielemi(a)hotmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, smaitra(a)redhat.com,
tfujiwar(a)redhat.com
Created attachment 1208438
--> https://bugzilla.redhat.com/attachment.cgi?id=1208438&action=edit
html page for test purpose
Description of problem:
My Fedora box is configured with two typing language between which I can
switch, English and Chinese.
I'm using Firefox v49 as browser.
I'm developing a webpage, a registration form using jQuery on the validation
part.
The registration form contain 4 input controls with 2 password controls, all
validated on the blur event. The form script is kind of complex one using blur,
and focus events and a list of functions.
The form script completely mess up on the live validation of the fields due to
the presence of the two password controls on which only latin alphabet is
allowed. The ibus language detector change on the fly when the two password
fields received focus causing blur and focus events of different contols to
happen in unexpected order. It is like ibus is taking the focus and releasing.
I tested both jQuery (all the available methods) and pure javascript with the
same result.
I had the chance to try other websites using blur and focus events on password
fields and are completely mess up too.
To finish my job I will unset the Chinese IME.
I can't guess what is about application development in the same context.
Version-Release number of selected component (if applicable):
Fedora 24 4.7.5-200.fc24.x86_64
ibus-1.5.13-3.fc24.x86_64
How reproducible:
https://jsfiddle.net/8tqwL7y5
Steps to Reproduce:
1. Settings, Region and Lanaguges, input sources: set English (US) and Chinese
(intelligent Pinyin)
2. try the link
3. try the webpage attached
Actual results:
Blur event doesn't happen or happen just mixed up with other events like other
control's Focus events.
Expected results:
Blur and Focus events get fired in common order on the events call stack
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 8 months
[Fedora-i18n-bugs] [Bug 1296121] New: XIM: When commiting with a space, it is inserted
before a hangul character rather than after it
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1296121
Bug ID: 1296121
Summary: XIM: When commiting with a space, it is inserted
before a hangul character rather than after it
Product: Fedora
Version: 23
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: psabata(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Description of problem:
This appears to be a recurring issue; I recall this was fixed a few times
already :) The behavior is similar to #675503. However, only XIM appears
to be affected this time; the input works fine in a GTK+v2 application.
Version-Release number of selected component (if applicable):
ibus-1.5.11-1.fc23.x86_64
ibus-libs-1.5.11-1.fc23.x86_64
ibus-hangul-1.5.0-5.fc23.x86_64
ibus-gtk2-1.5.11-1.fc23.x86_64
How reproducible:
Always with XIM. Never with GTK+v2.
Steps to Reproduce:
1. Run ibus with XIM
ibus-daemon -x
2. Set your environment and run something that uses it, e.g. xterm --
export XMODIFIERS='@im=ibus'
xterm
3. Type some hangul and commit with a space, e.g. "하나 둘 셋"
(input being "gksk enf tpt ")
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=cxyVQxcKBJ&a=cc_unsubscribe
5 years, 8 months
[Fedora-i18n-bugs] [Bug 1398181] New: Start at hangul does not work
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1398181
Bug ID: 1398181
Summary: Start at hangul does not work
Product: Fedora
Version: 25
Component: ibus
Severity: medium
Assignee: tfujiwar(a)redhat.com
Reporter: hwhwang7(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, smaitra(a)redhat.com,
tfujiwar(a)redhat.com
Description of problem:
After the input source 'hangul', I can enable the option 'start at hangul
mode'.
Even after I enabled it, whenever I switch to hangul, it does not start at
hangul mode.
Version-Release number of selected component (if applicable):
IBus 1.5.14
How reproducible:
Always
Steps to Reproduce:
1. Add the input source 'hangul'
2. Enable the option 'start at hangul mode'.
3. Switch input mode
Actual results:
Hangul mode does not start as enabled
Expected results:
Hangul mode starts as enabled
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 9 months
[Fedora-i18n-bugs] [Bug 1586296] New: [abrt] ibus-libpinyin: pinyin_save(): ibus-engine-libpinyin killed by SIGSEGV
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1586296
Bug ID: 1586296
Summary: [abrt] ibus-libpinyin: pinyin_save():
ibus-engine-libpinyin killed by SIGSEGV
Product: Fedora
Version: 28
Component: ibus-libpinyin
Assignee: pwu(a)redhat.com
Reporter: tcfxfzoi(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pwu(a)redhat.com
Version-Release number of selected component:
ibus-libpinyin-1.10.0-1.fc28
Additional info:
reporter: libreport-2.9.5
backtrace_rating: 4
cmdline: /usr/libexec/ibus-engine-libpinyin --ibus
crash_function: pinyin_save
executable: /usr/libexec/ibus-engine-libpinyin
journald_cursor:
s=52e1c1c145d84b2cb155ffe9c107ba83;i=3b1b73;b=dae3461a0e2945be9e92f08f92ce0837;m=321644364f;t=56ded81d26ea8;x=106dd56aa4eeefd0
kernel: 4.16.13-300.fc28.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 pinyin_save at pinyin.cpp:736
#1 PY::LibPinyinBackEnd::clearPinyinUserData at PYLibPinyin.cc:307
#2 PY::PinyinConfig::valueChanged(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, _GVariant*) at PYLibPinyin.h:60
#3 PY::LibPinyinConfig::valueChangedCallback(_GSettings*, char const*,
PY::LibPinyinConfig*) at /usr/include/c++/8/bits/char_traits.h:320
#8 g_settings_real_change_event at gsettings.c:386
#9 ffi_call_unix64 at ../src/x86/unix64.S:76
#10 ffi_call at ../src/x86/ffi64.c:525
#11 g_cclosure_marshal_generic_va at gclosure.c:1604
#12 _g_closure_invoke_va at gclosure.c:867
#15 settings_backend_path_changed at gsettings.c:461
Potential duplicate: bug 1568208
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 9 months
[Fedora-i18n-bugs] [Bug 1589008] New: Regression with 2.24: XKB_DEFAULT_OPTIONS not interpreted properly as with 2.23
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1589008
Bug ID: 1589008
Summary: Regression with 2.24: XKB_DEFAULT_OPTIONS not
interpreted properly as with 2.23
Product: Fedora
Version: rawhide
Component: xkeyboard-config
Assignee: peter.hutterer(a)redhat.com
Reporter: jpokorny(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, alexl(a)redhat.com,
caillon+fedoraproject(a)gmail.com,
i18n-bugs(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, mbarnes(a)fastmail.com,
negativo17(a)gmail.com, peter.hutterer(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com
I am setting these environment variables:
export XKB_DEFAULT_LAYOUT=us,cz
export XKB_DEFAULT_OPTIONS=caps:swapescape,grp:shift_caps_toggle,grp_led:scroll
However, after said upgrade, this configuration doesn't work properly
in sway WM (IIRC, cannot exchange layout with SHIFT+CAPS and "CAPS - ESC swap"
doesn't work as expected, either -- ESC will work as ordinary CAPS but
not vice-versa, but at least double ESC has the effect of ordinary "ESC").
Currently, I am forced to stay at 2.23.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 9 months