[Bug 1964374] New: stardict scan hotkey doesn't work
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1964374
Bug ID: 1964374
Summary: stardict scan hotkey doesn't work
Product: Fedora
Version: 33
Status: NEW
Component: stardict
Assignee: psatpute(a)redhat.com
Reporter: antmak.pub(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: anish.developer(a)gmail.com,
i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, robinlee.sysu(a)gmail.com,
yanqiyu01(a)gmail.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The "Use scan hotkey:" option from StarDict's Preferences doesn't work
Version-Release number of selected component (if applicable):
stardict-3.0.6-15.fc33.x86_64
Fedore 33
GNOME @ Wayland session
How reproducible:
Just change the option to any value, it doesn't work.
Steps to Reproduce:
1. Open StarDict
2. Open Preferences, "Scan Selection" tab
3. Enable "Use scan hotkey" option.
4. Values: "<Primary><Alt>x", "<Super>j", "<Primary><Alt>j" don't work - it
can't scan selected words from other windows like Firefox or Gedit
Actual results:
It should scan selected words in other apps and open a translate window
Expected results:
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
11 months, 2 weeks
[Fedora-i18n-bugs] [Bug 1847347] New: gnome-terminal and xfce4-terminal get surrounding text from previous application
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1847347
Bug ID: 1847347
Summary: gnome-terminal and xfce4-terminal get surrounding text
from previous application
Product: Fedora
Version: 32
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: mfabian(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
Target Milestone: ---
Classification: Fedora
I made the following screenshots and video by testing on Gnome-Xorg, but the
problem occurs on Gnome-Wayland as well.
How to reproduce (see also attached screenshots and video):
- To show what happens with the surrounding text, I first opened the
setup tool of ibus-typing-booster and set the debug level in the
options tab to 3.
When the debug level is high, the auxiliary text above the candidate
list shows what context has been obtained by using surrounding text
(if surrounding text is available, if it is not available like when
using xterm, the context is just remembered from what was typed
last).
- I opened 3 windows: gedit, firefox, and gnome-terminal.
- I focus on gedit and type "a b c d e"
On top of the candidate list one can see: "Context: b c d"
This is because when the letter "e" was typed, ibus-typing-booster
got the surrounding text at the cursor position and parsed the last
3 tokens left of the cursor out of the result. And these
last 3 tokens left of the cursor are "b c d".
- Now I focus on firefox and type "f g h i j"
On top of the candidate list one can see: "Context: g h i"
I.e. the correct context "g h i" to the left of the just typed "j"
(which is still in preedit) has been found using surrounding text.
- Now I focus on gnome-terminal and type "k l m"
On top of the candidate list one can see: "Context h i j"
This comes from the surrounding text left of the cursor in
*firefox*, *not* from gnome-terminal.
Although gnome-terminal reports that surrounding text is supported, i.e.
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is True (see the code to get the context at:
https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hun...
)
gnome-terminal does not really seem to support surrounding text.
The surrounding text comes from the previous client which really supported
surrounding text.
If the previous client was firefox, one still gets the surrounding text from
firefox while typing in gnome-terminal.
Same with gedit, if the previous client before focussing on gnome-terminal
was gedit, one still gets the surrounding text from gedit while typing in
gnome-terminal.
- The same problem occurs when using xfce4-terminal instead of gnome-terminal.
- When using xterm, the problem does *not* occur because when using xterm
self.client_capabilities & IBus.Capabilite.SURROUNDING_TEXT
is False and then the get_context() immediately returns and the context
remembered from the last text typed is used as a fallback.
--
You are receiving this mail because:
You are on the CC list for the bug.
11 months, 2 weeks
[Fedora-i18n-bugs] [Bug 1779123] New: Pango no longer supports type1 fonts
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1779123
Bug ID: 1779123
Summary: Pango no longer supports type1 fonts
Product: Fedora
Version: rawhide
Status: NEW
Component: pango
Assignee: pwu(a)redhat.com
Reporter: mjg(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
In pango 1.44, pango dropped support for type1 fonts. Therefore, no application
which uses pango for font loading can use type1 fonts any more.
Version-Release number of selected component (if applicable):
pango-1.44.6-1.fc31.x86_64 (and later)
How reproducible:
always
Steps to Reproduce:
1. Upgrade F31 or rawhide
2. Open any pango-using application
3. Try to use type1 font
Actual results:
No type1 font is usable
Expected results:
Type1 font is usable
Additional info:
bug 1753295 is the same bug for dropped bitmap font support. Over there,
workarounds specific for bitmap fonts (conversion to opentype bitmap fonts) are
discussed. An attempt to discuss type1 there failed.
This bug here is specifically about type1 fonts to discuss ways (or their
absence) to deal with pangos dropped type 1 support.
--
You are receiving this mail because:
You are on the CC list for the bug.
12 months
[Fedora-i18n-bugs] [Bug 1895482] New: Liberation Fonts Support For Serbian locl Glyphs Incomplete
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1895482
Bug ID: 1895482
Summary: Liberation Fonts Support For Serbian locl Glyphs
Incomplete
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: liberation-fonts
Assignee: vishalvijayraghavan(a)gmail.com
Reporter: aleslavista(a)outlook.it
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
petersen(a)redhat.com, psatpute(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com, vishalvijayraghavan(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1727218
--> https://bugzilla.redhat.com/attachment.cgi?id=1727218&action=edit
Correctly Localized Glyphs
Description of problem:
Liberation Fonts do NOT provide full support for Serbian localized glyphs.
Version-Release number of selected component (if applicable):
Liberation-Fonts 2.1-1-1
How reproducible:
You need a program that is able to access the font's localized glyphs: usually
that's LibreOffice Writer.
Steps to Reproduce:
1. Open LibreOffice Writer
2. Type бгдпт, then бгдпт in Italic, бгдпт in Bold and finally бгдпт in Italic
Bold with Liberation Serif, and do the same with Liberation Sans
3. Set the language to "Serbian Cyrillic"
Actual results:
Not all glyphs are correctly localized
Expected results:
See attachment for correctly localized glyphs
Additional info:
Liberation Mono has slanted Italic, therefore only the first glyph should be
localized: CYRILLIC LETTER SMALL BE.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year
[Fedora-i18n-bugs] [Bug 1767976] New: [abrt] ibus: bus_dbus_impl_connection_filter_cb(): ibus-daemon killed by SIGABRT
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1767976
Bug ID: 1767976
Summary: [abrt] ibus: bus_dbus_impl_connection_filter_cb():
ibus-daemon killed by SIGABRT
Product: Fedora
Version: 31
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:b24defc317ee932c47b15b9c24c231f607dad274;VAR
IANT_ID=workstation;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: rauch.christian(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-1.5.21-3.fc31
Additional info:
reporter: libreport-2.10.1
backtrace_rating: 4
cgroup:
0::/user.slice/user-1001.slice/user@1001.service/gnome-shell-wayland.service
cmdline: ibus-daemon --panel disable -r --xim
crash_function: bus_dbus_impl_connection_filter_cb
executable: /usr/bin/ibus-daemon
journald_cursor:
s=3ad93f33cf144f27b2bc4f480d8f3f2e;i=4b9e;b=9037b22bbad44adc83ebb6c1be09e1fc;m=1975f869;t=594e3ce75700c;x=34f5463c97ecc8bd
kernel: 5.3.5-300.fc31.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1001
Potential duplicate: bug 1475710
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 4 months
[Fedora-i18n-bugs] [Bug 1842034] New: [abrt] ibus: bus_dbus_impl_connection_filter_cb(): ibus-daemon killed by SIGABRT
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1842034
Bug ID: 1842034
Summary: [abrt] ibus: bus_dbus_impl_connection_filter_cb():
ibus-daemon killed by SIGABRT
Product: Fedora
Version: 32
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:b24defc317ee932c47b15b9c24c231f607dad274;VAR
IANT_ID=workstation;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: niki.guldbrand(a)gmail.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
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-1.5.22-7.fc32
Additional info:
reporter: libreport-2.13.1
backtrace_rating: 4
cgroup: 0::/user.slice/user-42.slice/session-c1.scope
cmdline: ibus-daemon --panel disable -r --xim
crash_function: bus_dbus_impl_connection_filter_cb
executable: /usr/bin/ibus-daemon
journald_cursor:
s=f592520f518043e0bf22bcb1059f85fa;i=5f0d;b=e5641f6c2ed84e629455c7ec8e6a1276;m=1c9e25e;t=5a6dbe50f3604;x=b9e38dca02503832
kernel: 5.6.15-300.fc32.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 42
Potential duplicate: bug 1475710
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 4 months
[Fedora-i18n-bugs] [Bug 1926996] New: [abrt] ibus: ibus_bus_connect_async(): ibus-x11 killed by SIGSEGV
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1926996
Bug ID: 1926996
Summary: [abrt] ibus: ibus_bus_connect_async(): ibus-x11 killed
by SIGSEGV
Product: Fedora
Version: rawhide
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:e9e25725fbf5b802310f7153823734fd779117b2;VAR
IANT_ID=workstation;
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: ivanbondar(a)gmail.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
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-1.5.23-4.fc34
Additional info:
reporter: libreport-2.14.0
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
cmdline: /usr/libexec/ibus-x11 --kill-daemon
crash_function: ibus_bus_connect_async
executable: /usr/libexec/ibus-x11
journald_cursor:
s=aab3f47a17be489baf33710542b2170a;i=f80;b=45370d40ccad4b839c075727799cd0e0;m=25b8493c;t=5baec3f2ba7c1;x=373238aeaa187c3d
kernel: 5.11.0-0.rc6.20210204git61556703b610.144.fc34.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (6 frames)
#0 ibus_bus_connect_async at
/usr/src/debug/ibus-1.5.23-4.fc34.x86_64/src/ibusbus.c:462
#1 _g_cclosure_marshal_VOID__OBJECT_OBJECT_ENUMv at
../gio/gmarshal-internal.c:1380
#2 _g_closure_invoke_va at ../gobject/gclosure.c:873
#5 g_file_monitor_source_dispatch at ../gio/glocalfilemonitor.c:567
#8 g_main_context_iterate.constprop.0 at ../glib/gmain.c:4131
#10 ibus_main at /usr/src/debug/ibus-1.5.23-4.fc34.x86_64/src/ibusshare.c:318
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 4 months
[Fedora-i18n-bugs] [Bug 1850832] New: The Gujarati & Hindi itrans methods are not able to type sentences correctly.
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1850832
Bug ID: 1850832
Summary: The Gujarati & Hindi itrans methods are not able to
type sentences correctly.
Product: Fedora
Version: 32
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus-m17n
Severity: high
Assignee: pnemade(a)redhat.com
Reporter: nirmalpathak(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, mfabian(a)redhat.com,
pnemade(a)redhat.com, shawn.p.huang(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1698739
--> https://bugzilla.redhat.com/attachment.cgi?id=1698739&action=edit
Actual result while typing in GEdit using Gujarati and Hindi using itrans(m17n)
input method.
Description of problem:
The Gujarati & Hindi itrans methods are not able to type sentences correctly.
When you start typing in Gujarati or Hindi using itrans(m17n) input method, the
letters at times are replaced by 'space' or it simply doesn't print. At times,
the special characters like "?" are printed before the previously typed/printed
character.
This happens abruptly but in most cases, once you enter a new line by pressing
'enter' or 'return' key and start new sentence.
Version-Release number of selected component (if applicable):
m17n-db-1.8.0-9.fc32.noarch
ibus-m17n-1.4.2-2.fc32.x86_64
m17n-lib-1.8.0-7.fc32.x86_64
How reproducible:
Type in Gujarati or Hindi language using ibus itrans(m17n) method.
Steps to Reproduce:
1. Select Gujarati (itrans - m17n) or Hindi (itrans - m17n) method from ibus
input method.
2. Start typing multiple sentences in Gujarati or Hindi.
3. Press 'enter' or 'return' key to start a new sentence in a new line.
Actual results:
- કે મછે?
- બરાબ રનથી લખાતું
- कै से ?हो
- ऐसा क्युं छ परहा है?
Expected results:
- કેમ છે?
- બરાબર નથી લખાતું
- कैसे हो?
- ऐसा क्युं छप रहा है?
Additional info:
Please check attached GIF image for actual results.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 4 months
[Fedora-i18n-bugs] [Bug 1751061] New: Compose doesn’t work when using ibus
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1751061
Bug ID: 1751061
Summary: Compose doesn’t work when using ibus
Product: Fedora
Version: 31
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: mfabian(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
Target Milestone: ---
Classification: Fedora
I installed Fedora-Everything-netinst-x86_64-31-20190909.n.0.iso in
qemu.
Ibus version is:
ibus-1.5.21-1.fc31.x86_64
I installed the gnome-tweaks package and set the compose key (Multi_key) to
“Scroll Lock”.
Configured input methods and keyboard layouts (as seen in the gnome panel) are:
English (US, euro on 5) en
日本語 ja
日本語(かな漢字) ja
その他(Typing Booster) 🚀
I choose the "English (US, euro on 5)" keyboard layout and
try to type into gedit.
When pressing <Multi_key> , I see
⎄
i.e. I see U+2384 COMPOSITION SYMBOL as expected.
But if I wait about a second, it disappears again.
Now I type <Multi_key> <'> fast, not waiting after <Multi_key>
I see
⎄'
and it disappears again after about a second.
<Multi_key> <'> <a> fast and I see:
á
After waiting for about a second, it turns into
á⎄
i.e. U+2384 COMPOSITION SYMBOL is added after the á without pressing any more
keys, just by waiting. This U+2384 COMPOSITION SYMBOL stays there, even if I
wait more. If I continue to type <'> <a>, I finally get:
áá
i.e. I have produced this “áá” by typing <Multi_key> <'> <a> <'> <a>.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 4 months