[Fedora-i18n-bugs] [Bug 1464310] New: Tilded G not works with Liberation Sans and Serif
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1464310
Bug ID: 1464310
Summary: Tilded G not works with Liberation Sans and Serif
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: shanshandehongxing_1234(a)hotmail.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
Description of problem:
Guarani letter G̃ does not works if I use Liberation Sans and Serif, this
letter requiring combining tilde.
Steps to Reproduce:
1. Coping this letter from https://en.wikipedia.org/wiki/Guarani_alphabet
2. Pasted into LibreOffice
3. Switch font face to Liberation Sans or Liberation Serif
Actual results:
With Liberation Sans/Serif tilded G does not works as expected.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 7 months
[Fedora-i18n-bugs] [Bug 1563448] New: [abrt] system-config-language: decode(): ascii.py:26: decode:UnicodeDecodeError: 'ascii' codec can' t decode byte 0xd0 in position 1513: ordinal not in range(128)
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1563448
Bug ID: 1563448
Summary: [abrt] system-config-language: decode():
ascii.py:26:decode:UnicodeDecodeError: 'ascii' codec
can't decode byte 0xd0 in position 1513: ordinal not
in range(128)
Product: Fedora
Version: 28
Component: system-config-language
Assignee: pnemade(a)redhat.com
Reporter: mastaizawfm(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, nav007(a)gmail.com,
pnemade(a)redhat.com, psatpute(a)redhat.com
Version-Release number of selected component:
system-config-language-3.4.2-6.fc28
Additional info:
reporter: libreport-2.9.4
cmdline: /usr/bin/python3
/usr/share/system-config-language/system-config-language.py
crash_function: decode
exception_type: UnicodeDecodeError
executable: /usr/share/system-config-language/system-config-language.py
interpreter: python3-3.6.4-20.fc28.x86_64
kernel: 4.16.0-0.rc7.git0.1.fc28.x86_64
runlevel: N 5
type: Python3
uid: 0
Truncated backtrace:
#1 decode in /usr/lib64/python3.6/encodings/ascii.py:26
#2 read_table in /usr/share/system-config-language/language_backend.py:94
#3 fill_store in /usr/share/system-config-language/language_gui.py:125
#4 __init__ in /usr/share/system-config-language/language_gui.py:60
#5 do_activate in /usr/share/system-config-language/language_gui.py:348
Potential duplicate: bug 1334022
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 7 months
[Fedora-i18n-bugs] [Bug 1084493] New: Missing MIDDLE DOT (u+00B7) glyph for Liberation Sans Italic
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1084493
Bug ID: 1084493
Summary: Missing MIDDLE DOT (u+00B7) glyph for Liberation Sans
Italic
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: jmontane(a)softcatala.org
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
Created attachment 882714
--> https://bugzilla.redhat.com/attachment.cgi?id=882714&action=edit
Screenshot showing the bug
Description of problem:
In Windows, there is no glyph for MIDDLE DOT (U+00B7) when using Liberation
Sans Italic, an empty space is showed.
Version-Release number of selected component (if applicable):
2.00.1
How reproducible:
Install Liberation Sans Italic files in a Windows machine (tested in Windows 7
32 and 64 bits). The esay way is installing LibreOffice 4.2, :)
Steps to Reproduce:
1. Open a new document LibreOffice Writer
2. Type "cel·la" (cell) "·" is U+00B7
3. Select "cel·la" text and set format as "Libreration Sans, Italic".
Actual results:
4.- "cel la" is showed in italics,you can copy and paste and set other font.
Expected results:
5.- "cel·la"
Additional info:
U+00B7 is a used character for Catalan text. So, please, fix this issue.
--
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=Z2jsEJyDVB&a=cc_unsubscribe
5 years, 7 months
[Fedora-i18n-bugs] [Bug 1554725] New: ibus emoji should hide missing characters by default
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1554725
Bug ID: 1554725
Summary: ibus emoji should hide missing characters by default
Product: Fedora
Version: 28
Component: ibus
Assignee: tfujiwar(a)redhat.com
Reporter: petersen(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:
I feel it is better to hide glyphs without font coverage by default.
Version-Release number of selected component (if applicable):
ibus-1.5.18-1.fc28
How reproducible:
100%
Steps to Reproduce:
1. ibus emoji lists glyphs with no font coverage.
(search for some less common character)
Actual results:
some tofu (unicode substitute character) glyphs listed
Expected results:
Better to hide missing glyphs by default
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 7 months
[Fedora-i18n-bugs] [Bug 1249335] New: Inconsistent rules for shortcuts between different applications when switching keymaps
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1249335
Bug ID: 1249335
Summary: Inconsistent rules for shortcuts between different
applications when switching keymaps
Product: Fedora
Version: 22
Component: ibus
Severity: medium
Assignee: tfujiwar(a)redhat.com
Reporter: nicolas.brack(a)mail.be
QA Contact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org,
shawn.p.huang(a)gmail.com, tfujiwar(a)redhat.com
I have this bug since a few fedora version. In some applications, the
shortcuts obeys the localized ibus keymap, but other keeps the default keymap
when pressing CTRL. Typical example includes gimp (follows keymap) and
inkscape (ignore keymap). I'm personally using both the us and dvorak keymap,
and this behaviour is pernicious as the key locations are very dissimilar.
Using "setxkbmap" is hard erasure of the keymap, and after that _all_
applications follows the keymap when using the shortcuts. But then ibus
doesn't really work anymore, and it's inconvenient.
Thus a solution could either be that:
*ibus is resilient to "setxkbmap"
*All software are presented with the same keymap, which can be configured to be
the current map.
Software versions:
GNOME Shell 3.16.3
IBus 1.5.10
Xorg 1.17.2
--
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=0xQlpdl2Ss&a=cc_unsubscribe
5 years, 7 months
[Fedora-i18n-bugs] [Bug 507262] New: Separate Japanese font configuration files for ghostscript
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: Separate Japanese font configuration files for ghostscript
https://bugzilla.redhat.com/show_bug.cgi?id=507262
Summary: Separate Japanese font configuration files for
ghostscript
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: japanese-bitmap-fonts
AssignedTo: tagoh(a)redhat.com
ReportedBy: t.matsuu(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Estimated Hours: 0.0
Classification: Fedora
I'm not sure which component should be assigned for this bug. So I initially
assign this bug to japanese-bitmap-fonts because the files for discussion is
now owned by japanese-bitmap-fonts package.
Description of problem:
Now
/usr/share/ghostscript/conf.d/CIDFnmap.ja
/usr/share/ghostscript/conf.d/FAPIcidfmap.ja
/usr/share/ghostscript/conf.d/cidfmap.ja
are owned by japanese-bitmap-fonts. But they never use fonts which are bundled
in japanese-bitmap-fonts.
Moreover, fonts which are set in the config files are dispersed among some
packages.
So we need to separate ghostscript contig files from japanese-bitmap-fonts and
they should be provided by another package (or included in ghostscript or
ghostscript-fonts package).
I suggest the following idea.
1. Universal
/usr/share/ghostscript/conf.d/{CIDFnmap.ja,FAPIcidfmap.ja,cidfmap.ja} is owned
by new (eg. ghostscript-fonts-japanese), ghostscript, or ghostscript-fonts
package.
2. Each Japanese fonts have their own CIDFnmap.ja, FAPIcidfmap.ja, and
cidfmap.ja files i their common package.
Discussion required:
* fonts priority
* file owner for ghostscript config files
* package structure of IPA fonts are not ready for generate common subpackage
now (bug 507261)
--
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.
5 years, 7 months
[Fedora-i18n-bugs] [Bug 1605054] New: Cursor becomes invisible in gnome-terminal after typing with ibus
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1605054
Bug ID: 1605054
Summary: Cursor becomes invisible in gnome-terminal after
typing with ibus
Product: Fedora
Version: 28
Component: ibus
Severity: medium
Assignee: tfujiwar(a)redhat.com
Reporter: vtgoal(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
Description of problem:
After typing in gnome-terminal with ibus input methods, cursor can becomes
invisible which is very inconvenient.
Version-Release number of selected component (if applicable):
Fedora 28 workstation x86_64
ibus-1.5.18-5.fc28.x86_64
ibus-libpinyin-1.10.0-1.fc28.x86_64 (or other Chinese input methods like
ibus-rime)
How reproducible:
100%
Steps to Reproduce:
1. Add Chinese (Intelligent Pinyin) as an input sources in Settings -> Region &
Language.
2. Open gnome-terminal
3. Switch to pinyin input (by press "Super" + "Space")
4. Typing, like "ceshi" to get the candidate words, Note: don't press "space"
to input a word, just stop at the list candidate words.
5. Press "Super" + "Press" to switch to another input method.
6. Now, in gnome-terminal, the cursor is disappeared.
This is one of the reproduce methods, switching to other windows while typing,
deleting all inputted letters while typing, may also trigger this. And this is
not limited to ibus-libpinyin only, other input methods like ibus-rime can
trigger this too.
Actual results:
Cursor in terminal disappears.
Expected results:
Cursor won't disappear.
Additional info:
From the same gnome-terminal tab, switch to Chinese input method, typing and
input a Chinese word can get the cursor back.
--
You are receiving this mail because:
You are on the CC list for the bug.
5 years, 7 months