[Bug 540411] New: [ml_IN] KDE applications display is too small with smc-meera-fonts
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: [ml_IN] KDE applications display is too small with smc-meera-fonts
https://bugzilla.redhat.com/show_bug.cgi?id=540411
Summary: [ml_IN] KDE applications display is too small with
smc-meera-fonts
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: smc-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: apeter(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, rajeeshknambiar(a)gmail.com,
smc-discuss(a)googlegroups.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Created an attachment (id=373059)
--> (https://bugzilla.redhat.com/attachment.cgi?id=373059)
Screenshot for Lokalize with smc-meera-fonts
Description of problem:
Login to Malayalam (ml_IN) locale where smc-meera-fonts is the default font,
the display of KDE applications like lokalize, kate etc looks very small when
compared with other applications. Screenshot attached for lokalize and kate
Version-Release number of selected component (if applicable):
smc-meera-fonts-04.2-2.fc12
How reproducible:
Always
Steps to Reproduce:
1. Login to gnome desktop in Malayalam locale
2. Open any keda applications like lokalize, kate
3. Compare the font size of these applications with any others
Actual results:
Reproducing above steps, you can observe that the kde applications' size is
small
Expected results:
The font size must be viewable enough or must be same like other applications
--
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.
10 years, 7 months
[Bug 528303] New: [ml_IN]Lohit font rendering of cons+virama+ra is wrong in KDE
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: [ml_IN]Lohit font rendering of cons+virama+ra is wrong in KDE
https://bugzilla.redhat.com/show_bug.cgi?id=528303
Summary: [ml_IN]Lohit font rendering of cons+virama+ra is wrong
in KDE
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: lohit-malayalam-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: santhosh.thottingal(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, smc-discuss(a)googlegroups.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Created an attachment (id=364359)
--> (https://bugzilla.redhat.com/attachment.cgi?id=364359)
Comparison of rendering in kde and gnome
Description of problem:
The lohit font 2.4.4 version gives wrong redering in KDE for cons + virama + ra
sequence.
See the attached screenshot.
The prebase ra sign becomes postbase in KDE applications, while in GNOME
applications it is correct.
Version-Release number of selected component (if applicable):
Lohit 2.4.4
KDE 4.3.2
How reproducible:
Always
Steps to Reproduce:
1. Compare the rendering of പ്രഭാതം, അക്രമം, സൂത്രം etc in gedit and kate
Actual results:
See the attached screenshot
Expected results:
See the attached screenshot
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.
10 years, 7 months
[Bug 705348] New: Byte-code interpreter seems not enabled in Qt
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: Byte-code interpreter seems not enabled in Qt
https://bugzilla.redhat.com/show_bug.cgi?id=705348
Summary: Byte-code interpreter seems not enabled in Qt
Product: Fedora
Version: 15
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: low
Priority: unspecified
Component: freetype
AssignedTo: mkasik(a)redhat.com
ReportedBy: arthur.kun(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org, kevin(a)tigcc.ticalc.org,
fonts-bugs(a)lists.fedoraproject.org, mkasik(a)redhat.com
Classification: Fedora
Story Points: ---
Created attachment 499346
--> https://bugzilla.redhat.com/attachment.cgi?id=499346
Comparison of font rendering between kwrite and gedit
Description of problem:
The font rendering in KDE/Qt apps looks like freetype byte-code interpreter
(BCI) is not enabled, while gtk apps renders fonts as BCI enabled.
Version-Release number of selected component (if applicable):
freetype-2.4.4-4.fc15.x86_64
qt-4.7.2-8.fc15.x86_64
How reproducible: every time
Steps to Reproduce:
1. Enable full hinting in KDE system settings
2. Open kwrite and gedit; select DejaVu Sans 12 as editor font in both
3. Open the same file in both editors
Actual results:
font rendering in kwrite (both menu and contents) looks like BCI not enabled
(poor hinting); while in gedit, BCI looks as working.
This difference applies to all Qt applications (KDE and non-KDE) and all
Gtk-based applications.
Expected results:
BCI enabled in both Qt and Gtk-based applications
Additional info:
I was using Fedora 15 RC3 downloaded from
http://serverbeach1.fedoraproject.org/pub/alt/stage/15.RC3/Fedora/x86_64/...
--
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.
10 years, 7 months
[Bug 715309] New: Bold 'u' looks skinny
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: Bold 'u' looks skinny
https://bugzilla.redhat.com/show_bug.cgi?id=715309
Summary: Bold 'u' looks skinny
Product: Fedora
Version: 15
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: liberation-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: mkasik(a)redhat.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
Story Points: ---
Created attachment 506011
--> https://bugzilla.redhat.com/attachment.cgi?id=506011
ftview of LiberationSans-Bold.ttf
Description of problem:
Letter 'u' from LiberationSans-Bold.ttf has vertical lines narrower than it
should have at size 18 (when comparing with 'n').
Version-Release number of selected component (if applicable):
liberation-sans-fonts-1.07.0-1.fc15
How reproducible:
execute "ftview 18 /usr/share/fonts/liberation/LiberationSans-Bold.ttf" (or see
the attached image) and compare letter 'u' with letter 'n'.
Additional info:
This was introduced in upstream commit
http://git.fedorahosted.org/git/?p=liberation-fonts.git;a=commit;h=054d32...
which is a fix of https://bugzilla.redhat.com/show_bug.cgi?id=463036.
--
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.
10 years, 8 months
[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.
10 years, 8 months
[Bug 694724] New: [kn_IN] 0CB0 + 200D + 0CCD + 0C95+ 0CBE consonant is wrongly rendering
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: [kn_IN] 0CB0 + 200D + 0CCD + 0C95+ 0CBE consonant is wrongly rendering
https://bugzilla.redhat.com/show_bug.cgi?id=694724
Summary: [kn_IN] 0CB0 + 200D + 0CCD + 0C95+ 0CBE consonant is
wrongly rendering
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: lohit-kannada-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: svenkate(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
psatpute(a)redhat.com, i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Story Points: ---
Created attachment 490712
--> https://bugzilla.redhat.com/attachment.cgi?id=490712
Actual and correct rendering
Description of problem:
ra+ ZWJ+ halanth + consonant + aa (0CB0 + 200D + 0CCD + 0C95+ 0CBE) is wrongly
rendering
Version-Release number of selected component (if applicable):
lohit-kannada-fonts-2.4.5-4.fc14.noarch
How reproducible:
Every time
Steps to Reproduce:
1.Open any text editor (say gedit)
2.Input following raw code key sequence:
0CB0 + 200D + 0CCD + 0C95+0CBE
3.Look at the resulting glyph
Actual results:
Shown in the attachment
Expected results:
Shown in the attachment
Additional info:
This was tested with following rendering engines:
libicu-4.4.1-6.fc14.x86_64
qt-4.7.1-17.fc14.x86_64
pango-1.28.1-5.fc14.x86_64
--
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.
10 years, 11 months
[Bug 545701] New: [kn_IN] Pango doesn't render 0c95+0ccd+0c95+0c97 combination properly
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: [kn_IN] Pango doesn't render 0c95+0ccd+0c95+0c97 combination properly
https://bugzilla.redhat.com/show_bug.cgi?id=545701
Summary: [kn_IN] Pango doesn't render 0c95+0ccd+0c95+0c97
combination properly
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: svenkate(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Created an attachment (id=377107)
--> (https://bugzilla.redhat.com/attachment.cgi?id=377107)
shows the actual and correct rendering
Description of problem:
Pango doesn't render a particular character combination properly.
Version-Release number of selected component (if applicable):
1.26.0-1.fc12
How reproducible:
Always
Steps to Reproduce:
1.Enable the Kannada support
2. Select the "inscript" layout from ibus menu, and type the following key
combination: j+d+j+>
OR
Select "other-rawcode" from ibus menu and type the following key combination
0c95+0ccd+0c95+0c97
Actual results:
ಕ್ಕಷ
Expected results:
As shown in the attached image
Additional info:
Reported upstream at https://bugzilla.gnome.org/show_bug.cgi?id=604060
--
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.
11 years
[Bug 760339] New: FreeType complains " couldn't find encoding 'iso8859-13'" for multiple local fonts
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: FreeType complains " couldn't find encoding 'iso8859-13'" for multiple local fonts
https://bugzilla.redhat.com/show_bug.cgi?id=760339
Summary: FreeType complains " couldn't find encoding
'iso8859-13'" for multiple local fonts
Product: Fedora
Version: 16
Platform: i686
OS/Version: Linux
Status: NEW
Severity: low
Priority: unspecified
Component: xorg-x11-fonts
AssignedTo: xgl-maint(a)redhat.com
ReportedBy: stern(a)rowland.harvard.edu
QAContact: extras-qa(a)fedoraproject.org
CC: xgl-maint(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org
Classification: Fedora
Story Points: ---
Type: ---
Description of problem: When X starts up, the Xorg log file contains multiple
lines like this:
FreeType: couldn't find encoding 'iso8859-13' for
'/usr/local/share/fonts/l047013t.pfa'
That particular font file doesn't belong to an RPM package; I inherited it from
a long time ago. In case you're interested about it:
$ grep l047013t /usr/local/share/fonts/fonts.dir
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-adobe-standard
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-ascii-0
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso10646-1
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso8859-1
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso8859-13
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso8859-15
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso8859-2
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-iso8859-9
l047013t.pfa -b&h-luxi mono-medium-r-normal--0-0-0-0-m-0-microsoft-cp1252
Regardless, the point is that the iso8859-13 encoding does indeed exist:
$ ls -l /usr/share/X11/fonts/encodings/iso8859-13*
-rw-r--r--. 1 root root 639 Jul 28 11:18
/usr/share/X11/fonts/encodings/iso8859-13.enc.gz
$ grep iso8859-13 /usr/share/X11/fonts/encodings/encodings.dir
iso8859-13 /usr/share/X11/fonts/encodings/iso8859-13.enc.gz
So why does FreeType complain so much? Or to put this another way, why doesn't
it also complain about the other fonts in /usr/local/share/fonts which use
other encodings, such as iso8859-15 above?
Version-Release number of selected component (if applicable):
xorg-x11-fonts-misc-7.5-4.fc15.noarch
libXft-2.2.0-2.fc15.i686
How reproducible: Always.
Expected results: FreeType should be able to find the encoding file, and not
fill the log with error messages.
--
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.
11 years, 2 months