[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
[Bug 2109358] New: emacs fails to start: Cannot open load file: No
such file or directory, comp
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2109358
Bug ID: 2109358
Summary: emacs fails to start: Cannot open load file: No such
file or directory, comp
Product: Fedora
Version: 36
Status: NEW
Component: emacs-common-ddskk
Assignee: dueno(a)redhat.com
Reporter: nicku(a)nicku.org
QA Contact: extras-qa(a)fedoraproject.org
CC: dueno(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem: emacs fails to start if emacs-ddsdk is installed
Version-Release number of selected component (if applicable):
16.2-12.fc36
How reproducible:
Always
Steps to Reproduce:
1.Install emacs, it runs
2.install emacs-ddsdk
3. Emacs refuses to start, with message, "Cannot open load file: No such file
or directory, comp"
Actual results:
Emacs refuses to start, with message, "Cannot open load file: No such file or
directory, comp"
Expected results:
emacs runs.
Additional info:
strace shows emacs looking iin so many places other than the right one.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2109358
11 months, 2 weeks
[Bug 2094689] New: [abrt] ibus-setup: dictkeys_decref(): python3.10
killed by SIGSEGV
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2094689
Bug ID: 2094689
Summary: [abrt] ibus-setup: dictkeys_decref(): python3.10
killed by SIGSEGV
Product: Fedora
Version: 36
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:5384a2084d3e5a0a50d73ac1d0f6702b6679e8e1;VAR
IANT_ID=workstation;
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
Description of problem:
Version-Release number of selected component:
ibus-setup-1.5.26-8.fc36
Additional info:
reporter: libreport-2.17.1
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/dbus-:1.2-com.redhat.imsettings@0.service
cmdline: python3 /usr/share/ibus/setup/main.py ibus-setup
crash_function: dictkeys_decref
executable: /usr/bin/python3.10
journald_cursor:
s=f4b06a7c90514868a0ecb24aa4a3d53e;i=66eb;b=3fc2379dae1240f58971d2cf0885b326;m=40d6d7d5;t=5e0eabf35c54a;x=e9d6ba44ac336a36
kernel: 5.17.13-300.fc36.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 dictkeys_decref at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:336
#1 dict_merge at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2588
#2 dict_update_common at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2428
#3 dict_update at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/dictobject.c:2446
#4 method_vectorcall_VARARGS_KEYWORDS at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Objects/descrobject.c:344
#5 _PyObject_VectorcallTstate at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:114
#6 PyObject_Vectorcall at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:123
#7 call_function at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:5867
#8 _PyEval_EvalFrameDefault at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:4198
#9 _PyEval_EvalFrame at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/internal/pycore_ceval.h:46
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2094689
11 months, 3 weeks
[Bug 2061664] New: IBus candidate panel show up at wrong positions
for QT apps
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2061664
Bug ID: 2061664
Summary: IBus candidate panel show up at wrong positions for QT
apps
Product: Fedora
Version: 36
Hardware: x86_64
OS: Linux
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: vtq-gnome(a)outlook.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: ---
Link ID: Red Hat Bugzilla 2060988
Classification: Fedora
Description of problem:
When I trying to input chinese text with ibus-libpinyin in QT apps (tested
texworks, okular, kwrite, konsole, fedora mediawriter, seemingly all QT apps),
the candidate character panel shows up not below the cursor but at a wrong
position, sometimes outside the window. This happens in both Wayland and Xorg
sessions, although the position is different for the two environments.
Version-Release number of selected component (if applicable):
Fedora-Workstation-Live-x86_64-36-20220307.n.0.iso image running on bare metal.
ibus-1.5.25-13.fc36
ibus-libpinyin-1.12.1-2.fc36
qt5-qtbase-5.15.2-33.fc36
How reproducible:
Always
Steps to Reproduce:
1. Boot from the live image
2. Add Intelligent Pinyin IME from Settings-Keyboard-Input Sources
3. Install some QT apps (e.g. kwrite)
4. Open kwrite, click the text field, use Super-Space to switch to Pinyin
input, and try to input some text
Actual results:
The candidate character panel shows up at a wrong position, sometimes outside
the window.
Expected results:
The candidate character panel should show up just below the text cursor.
Additional info:
Bug 2060988 for Wayland seems to be related. But this is happening in Xorg
session too.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2061664
11 months, 3 weeks
[Bug 2093859] New: [abrt] ibus-anthy-python: _Py_INCREF():
python3.10 killed by SIGSEGV
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2093859
Bug ID: 2093859
Summary: [abrt] ibus-anthy-python: _Py_INCREF(): python3.10
killed by SIGSEGV
Product: Fedora
Version: 36
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:cf7f44bcb9c2c2815bdb65cb37a42f3598ad0a67;VAR
IANT_ID=workstation;
Component: ibus-anthy
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, tagoh(a)redhat.com,
tfujiwar(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Version-Release number of selected component:
ibus-anthy-python-1.5.14-4.fc36
Additional info:
reporter: libreport-2.17.1
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/app.slice/dbus-:1.2-com.redhat.imsettings@0.service
cmdline: python3 /usr/share/ibus-anthy/engine/main.py --ibus
crash_function: _Py_INCREF
executable: /usr/bin/python3.10
journald_cursor:
s=0325f794070a4f0cbc4530c1f3e0ce87;i=251fb;b=a1249be8f9ec419eb97f1227a35e5fc0;m=87fad6a;t=5e062559eddf7;x=20a00219da6db34b
kernel: 5.17.11-300.fc36.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (10 frames)
#0 _Py_INCREF at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/object.h:472
#1 _PyEval_EvalFrameDefault at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:2806
#2 _PyEval_EvalFrame at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/internal/pycore_ceval.h:46
#3 _PyEval_Vector at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:5065
#4 _PyObject_VectorcallTstate at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:114
#5 PyObject_Vectorcall at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/cpython/abstract.h:123
#6 call_function at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:5867
#7 _PyEval_EvalFrameDefault at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:4213
#8 _PyEval_EvalFrame at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Include/internal/pycore_ceval.h:46
#9 _PyEval_Vector at
/usr/src/debug/python3.10-3.10.4-1.fc36.x86_64/Python/ceval.c:5065
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2093859
12 months
[Bug 2013323] New: Cursor position and conversion regioni of
ibus-anthy are invisible in Google Documents (both in firefox and
google-chrome)
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2013323
Bug ID: 2013323
Summary: Cursor position and conversion regioni of ibus-anthy
are invisible in Google Documents (both in firefox and
google-chrome)
Product: Fedora
Version: 34
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
Created attachment 1832255
--> https://bugzilla.redhat.com/attachment.cgi?id=1832255&action=edit
Video showing the wrongly displayed cursor position using ibus-anthy in Google
Documents
I did choose component ibus, although this is likely not an ibus bug but a
problem in google docs, but I wanted to report it somehow, maybe something can
be done to improve this:
Fedora-Workstation-Live-x86_64-35-20210829.n.0.iso installed in qemu-kvm with
all current updates.
firefox-93.0-2.fc35.x86_64
google-chrome-unstable-96.0.4662.6-1.x86_64
ibus-1.5.25-4.fc35.x86_64
ibus-anthy-1.5.13-1.fc35.x86_64
See the attached video.
In the video I type わたしのなまえはやまだです first in gedit to show how it should work.
After typing that hiragana, I type space to start conversion. The current
conversion region is indicated by the cursor position and a purple background
color. When the conversion to kanji is startet, at first the cursor position is
at the left of the preedit and the conversion region is わたしの. I can then move
the conversion region right with arrow-right and see that it moves because the
blue background and the cursor position moves.
Then I do the same in Google Documents (both in firefox and google-chrome, that
makes no difference):
- The cursor position is *always* shown at the right end of the preedit
- The purple background color of the conversion region is not there
One can move the conversion region around using the arrow keys, one just cannot
see where the conversion region currently is the purple background is missing
*and* the cursor position is *always* at the right end of the preedit.
The same problem happens when trying to use ibus-typing-booster with the
"inline completion" option in Google Documents. The color of the inline
completion is missing *and* the cursor position is always at the end of the
preedit, so one cannot see where the inline completion is and whether it has
been accepted or not.
In gedit in wayland, the colors don't work either, but at least the cursor
position is shown correctly. When only the cursor position is shown but no
color, it is not great at least somewhat usable. By carefully watching the
cursor one can still see what is going on. But when the cursor positon is
always at the right of preedit *and* there is no colour, this is completely
unusable.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2013323
1 year
[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.
1 year
[Bug 1993618] New: [abrt] ibus-libpinyin:
PY::PunctEditor::moveCursorToBegin(): ibus-engine-libpinyin killed by SIGABRT
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1993618
Bug ID: 1993618
Summary: [abrt] ibus-libpinyin:
PY::PunctEditor::moveCursorToBegin():
ibus-engine-libpinyin killed by SIGABRT
Product: Fedora
Version: 34
Hardware: x86_64
Status: NEW
Whiteboard: abrt_hash:e41f218ee5601bc1377bb63d92ea7cfafa49f6df;VAR
IANT_ID=workstation;
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
Target Milestone: ---
Classification: Fedora
Version-Release number of selected component:
ibus-libpinyin-1.12.0-3.fc34
Additional info:
reporter: libreport-2.15.2
backtrace_rating: 4
cgroup:
0::/user.slice/user-1000.slice/user@1000.service/session.slice/org.gnome.Shell@wayland.service
cmdline: /usr/libexec/ibus-engine-libpinyin --ibus
crash_function: PY::PunctEditor::moveCursorToBegin
executable: /usr/libexec/ibus-engine-libpinyin
journald_cursor:
s=b843de467070413eac4da2bc5d966ff5;i=701f;b=c1ce31806f0448d2826bedd20c47fa6b;m=99564a78;t=5c986a4580fd5;x=bf2d4d76d0a056b9
kernel: 5.13.9-200.fc34.x86_64
rootdir: /
runlevel: N 5
type: CCpp
uid: 1000
Truncated backtrace:
Thread no. 1 (9 frames)
#4 PY::PunctEditor::moveCursorToBegin at
/usr/src/debug/ibus-libpinyin-1.12.0-3.fc34.x86_64/src/PYPunctEditor.cc:317
#5 PY::PunctEditor::processKeyEvent at
/usr/src/debug/ibus-libpinyin-1.12.0-3.fc34.x86_64/src/PYPunctEditor.cc:190
#6 PY::BopomofoEngine::processKeyEvent at
/usr/src/debug/ibus-libpinyin-1.12.0-3.fc34.x86_64/src/PYPBopomofoEngine.cc:198
#8 _ibus_marshal_BOOLEAN__UINT_UINT_UINT at
/usr/src/debug/ibus-1.5.24-5.fc34.x86_64/src/ibusmarshalers.c:280
#13 ibus_engine_service_method_call at
/usr/src/debug/ibus-1.5.24-5.fc34.x86_64/src/ibusengine.c:1107
#14 call_in_idle_cb at ../gio/gdbusconnection.c:4913
#18 g_main_context_iterate.constprop.0 at ../glib/gmain.c:4131
#20 ibus_main at /usr/src/debug/ibus-1.5.24-5.fc34.x86_64/src/ibusshare.c:322
#21 start_component at
/usr/src/debug/ibus-libpinyin-1.12.0-3.fc34.x86_64/src/PYMain.cc:141
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year
[Bug 2062619] New: IBus stop working after locking screen
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2062619
Bug ID: 2062619
Summary: IBus stop working after locking screen
Product: Fedora
Version: rawhide
Status: NEW
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: tagoh(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
Description of problem:
When I keep preediting on apps and the screen is locked by idle, IBus stop
working after unlocking.
Version-Release number of selected component (if applicable):
ibus-1.5.25-13.fc36.x86_64
How reproducible:
always
Steps to Reproduce:
1.Install Workstation from Live
2.Setup with ja
3.Open LibreOffice Writer
4.Type something on preedit and wait for locking the screen
5.Unlock the screen
Actual results:
Unable to input through IBus on apps
Expected results:
Able to input through IBus
Additional info:
IBus get back after changing the focus for example.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2062619
1 year
[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