[Fedora-i18n-bugs] [Bug 1014357] New: U+266B incorrect glyph with extra beam
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1014357
Bug ID: 1014357
Summary: U+266B incorrect glyph with extra beam
Product: Fedora
Version: rawhide
Component: liberation-fonts
Assignee: psatpute(a)redhat.com
Reporter: fabian+redhat(a)greffrath.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
Originally reported as Debian #724839 [1] by Drake Wilson:
"
Using gucharmap 1:3.8.2-2 to view Liberation Serif characters with "Show only
glyphs from this font" enabled, the glyph for U+266B BEAMED EIGHTH NOTES shows
what is clearly beamed sixteenth notes instead; it should have only one beam
rather than two. FontForge confirms this after opening
LiberationSerif-Regular.ttf with SHA-256 =
ea76595ed32ec4bb117fc715e393b4cca3d42cabe53101baec6bbbeb800fa26a.
The glyph for U+266C BEAMED SIXTEENTH NOTES is correct.
"
The bug has been reported against version 2.00.1, ut I have checked with 1.07.3
and it is also present in this version.
Best regards,
Fabian
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724839
--
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=PXTyqCv0jP&a=cc_unsubscribe
4 years, 9 months
[Fedora-i18n-bugs] [Bug 803646] New: Password is visible on gnome-terminal with English-typing-booster enabled
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: Password is visible on gnome-terminal with English-typing-booster enabled
https://bugzilla.redhat.com/show_bug.cgi?id=803646
Summary: Password is visible on gnome-terminal with
English-typing-booster enabled
Product: Fedora
Version: 17
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: ibus-european-table
AssignedTo: apatil(a)redhat.com
ReportedBy: apeter(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: i18n-bugs(a)lists.fedoraproject.org, apatil(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Created attachment 570253
--> https://bugzilla.redhat.com/attachment.cgi?id=570253
Password being displayed on terminal
Description of problem:
With English-typing-booster enabled on gnome-terminal, while using su- command,
password appears in the text.
Version-Release number of selected component (if applicable):
english-typing-booster-0.0.2-1.fc17
How reproducible:
Always
Steps to Reproduce:
1. Enable English-typing-booster
2. Go to terminal
3. Try to become root with su-
4. Type your password
Actual results:
Perform above steps, you can see the password is shown on the screen.
Expected results:
Password must not be shown.
Additional info:
--
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.
4 years, 10 months
[Fedora-i18n-bugs] [Bug 825115] New: [kn_IN] Lohit Kannada glyphs of consonants with vowel signs -II, -EE, -OO and -AI should be optimized
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=825115
Bug ID: 825115
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
Version: 16
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: [kn_IN] Lohit Kannada glyphs of consonants with vowel
signs -II, -EE, -OO and -AI should be optimized
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: samjnaa(a)gmail.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: lohit-kannada-fonts
Product: Fedora
Description of problem:
Currently the Lohit Kannada fonts unnecessarily contain separate glyphs for
consonants with vowel signs -II, -EE, -OO and -AI. These are merely sequences
of other glyphs.
In the case of -II, -EE, -OO the glyphs are the same as those of the
corresponding short vowels plus a separate glyph 0CD5 Kannada Length Mark ೕ
(unlike in Telugu where the length mark ligates with the syllable). Therefore
instead of doing substitutions of:
CONSONANT + VOWEL_SIGN_II/EE/OO --> CONSONANT_VOWELSIGN_II/EE/OO
the optimized way would be to do:
CONSONANT + VOWEL_SIGN_II/EE/OO --> CONSONANT_VOWELSIGN_I/E/O LENGTH_MARK
If this is done, any changes that are reflected on the
CONSONANT_VOWELSIGN_I/E/O glyphs would automatically reflect for the long
vowels as well without additional work being needed. For instance, see my
recent report of bug 825104. If that bug is fixed for short vowels I, E and O,
automatically it would reflect for II, EE and OO also.
As for -AI, it is merely sequence of glyph for -E plus 0CD6 Kannada AI Length
Mark ೖ. So instead of doing substitutions of:
CONSONANT + VOWEL_SIGN_AI --> CONSONANT_VOWELSIGN_AI
the optimized way would be to do:
CONSONANT + VOWEL_SIGN_AI --> CONSONANT_VOWELSIGN_E AI_LENGTH_MARK
with same benefits as above.
Further, when handling combinations of:
CONSONANT1 + VIRAMA + CONSONANT2 + VOWEL_SIGN_II/EE/OO/AU
by separating the length mark as recommended here, the sub-base form of
CONSONANT2 can be placed closer to the base CONSONANT1 which is also
typographically a desirable factor in a good font. The rules would be:
CONSONANT1 + VIRAMA + CONSONANT2 + VOWEL_SIGN_II/EE/OO/AU -->
CONSONANT1_VOWEL_SIGN_I/E/O + SUB_BASE_CONSONANT_2 + (AI_)LENGTH_MARK
Version-Release number of selected component (if applicable):
2.5.1
How reproducible:
Examine the internals of Lohit Kannada font.
Actual results:
Currently there are separate glyphs for consonants with vowel signs -II, -EE,
-OO and -AI unnecessarily. These are merely sequences of other glyphs.
Therefore any change effected on the component glyphs has to be re-done here.
Expected results:
The superfluous glyphs should be removed and the appropriate effect should be
achieved by appropriate smartfont rules as indicated above.
Additional info:
This would also reduce the size of the font. Not an issue on laptops/desktops
but nowadays Lohit fonts are finding their way into smaller screens such as
smartphones, and it would be good to have a trim font with small footprint.
--
You are receiving this mail because:
You are on the CC list for the bug.
4 years, 10 months
[Fedora-i18n-bugs] [Bug 1133127] New: The hotkey for switching to direct input mode should be configurable
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1133127
Bug ID: 1133127
Summary: The hotkey for switching to direct input mode should
be configurable
Product: Fedora
Version: 19
Component: ibus-table
Assignee: mfabian(a)redhat.com
Reporter: stsp(a)list.ru
QA Contact: extras-qa(a)fedoraproject.org
CC: dchen(a)redhat.com, extras-qa(a)fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, kent.neo(a)gmail.com,
me(a)kaio.net, mfabian(a)redhat.com, pwu(a)redhat.com,
shawn.p.huang(a)gmail.com, stsp(a)list.ru
+++ This bug was initially created as a clone of Bug #1128912 +++
(In reply to Stas Sergeev from comment #23)
> I noticed another problem.
> When I type, the layout ocasionally changes back
> to EN, even though I do not press the modifier combo.
> The switcher applet still shows RU, but the typing
> becomes latinic.
> Presumably this happens after Shift-Space, but again,
> not always... So we have another puzzle. I wonder if
> you can make a sharp guess or reproduce that...
You are switching between table mode ("rusle") and direct input mode
(using the underlying keyboard layout directly).
The hotkey for this is the left shift key (Without space, just
left shift and release it).
You can see which mode you are in if you open the input method menu in
the gnome panel while rusle is active. Look at the 4 menu entries near
the bottom:
Direct input (Left Shift)
Phrase mode (Ctrl-;) <- quite useless for rusle
Direct commit mode (Ctrl-/) <- quite useless for rusle
Setup
If you hit the left shift key and look again, you see that the topmost
of these "property" menus toggles between
Direct input (Left Shift) <-> Р (Left Shift)
I am not sure what I can do about this now.
For Chinese, this is used often as a quick way to toggle between
Chinese and English mode (faster than switching between two input
sources). That might be the reason why the original developer of
ibus-table did choose the left shift key as the hot key for that.
The disadvantage is of course that the left shift key can be hit far
too easily.
In the long run, I want to make the keybindings configurable, then
you could set that keybinding to empty. But I have no time for that
soon, that is a bit more work.
Choosing a different shortcut is not nice to existing users.
Disabling that shortcut for non-CJK input methods might also be
not so nice. Maybe one wants to quickly toggle between direct
input and a non-CJK input method as well.
So I am a bit puzzled what to do about this now.
Maybe wait until I have time to make the keybindings configurable?
--- Additional comment from Stas Sergeev on 2014-08-22 15:32:52 EDT ---
> Maybe wait until I have time to make the keybindings configurable?
Maybe I have no other option than to agree with this? :)
Anyway, another sharp guess, you are right, left shift
is the culprit. Thank you.
So, should I open a separate report for this or what?
--- Additional comment from Stas Sergeev on 2014-08-22 15:34:22 EDT ---
(In reply to Mike FABIAN from comment #24)
> Created attachment 929759 [details]
> 0001-Ignore-Shift-Space-hotkey-to-switch-fullwidth-halfwi.patch
>
> To fix the problem in comment#21
Patch tested and works.
--- Additional comment from Mike FABIAN on 2014-08-22 15:55:18 EDT ---
(In reply to Stas Sergeev from comment #26)
> > Maybe wait until I have time to make the keybindings configurable?
> Maybe I have no other option than to agree with this? :)
> Anyway, another sharp guess, you are right, left shift
> is the culprit. Thank you.
>
> So, should I open a separate report for this or what?
Yes, I think a separate bug report is helpful so I do not forget this.
Maybe, as a temporary workaround, I disable that hotkey for non-CJK
and enable it again as soon as the hotkeys are configurable.
I really should make the hotkeys configurable ...
--
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=DFaAYcdVbL&a=cc_unsubscribe
4 years, 11 months
[Fedora-i18n-bugs] [Bug 657849] New: Serbian glyphs for Wikipedia
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: Serbian glyphs for Wikipedia
https://bugzilla.redhat.com/show_bug.cgi?id=657849
Summary: Serbian glyphs for Wikipedia
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: medium
Priority: low
Component: liberation-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: alessandroceschini.it(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Description of problem:
Hy, at the Serbian Wikipedia we are planning on supporting localized Serbian
glyphs (as opposed to standard/Russian ones) on screen by taking advantage of
the next generation of browser (like Firefox 4) compliant with OpenType
features.
What we lack is a pool of free OpenType fonts with Serbian glyphs to be
accessed through the locl feature. DejaVu is, as far as I know, the only free
font which does so (although with some bugs) but, particularly the Serif
version, can be described as ugly at best.
So, what about a new release of Liberation Fonts containing a locl table for
Serbian?
Thank you.
--
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