[Bug 534118] New: Coredump on exit from X Windows in FontFileFreeDir
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: Coredump on exit from X Windows in FontFileFreeDir
https://bugzilla.redhat.com/show_bug.cgi?id=534118
Summary: Coredump on exit from X Windows in FontFileFreeDir
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: libXfont
AssignedTo: sandmann(a)redhat.com
ReportedBy: zkabelac(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: sandmann(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
While doing exit of Xorg - I'm getting this coredump:
#0 malloc_consolidate (av=<value optimized out>) at malloc.c:5136
#1 0x00007f2f45461fc8 in _int_free (av=0x7f2f4575ee80, p=0x32c2490,
have_lock=0) at malloc.c:5015
#2 0x00007f2f4770584c in FontFileFreeDir (dir=0x3291bb0) at fontdir.c:170
#3 0x00007f2f47707454 in FontFileFreeFPE (fpe=0x3291b40) at fontfile.c:144
#4 0x00007f2f477092c4 in CatalogueUnrefFPEs (fpe=<value optimized out>) at
catalogue.c:116
#5 0x00007f2f477099b8 in CatalogueFreeFPE (fpe=0x3280e60) at catalogue.c:272
#6 0x000000000042e4b6 in FreeFPE (fpe=0x3280e60) at dixfonts.c:225
#7 0x000000000042e507 in FreeFontPath (list=0x3280e30, n=4, force=1) at
dixfonts.c:1661
#8 0x000000000042e5c7 in FreeFonts () at dixfonts.c:2028
#9 0x0000000000421dc4 in main (argc=<value optimized out>, argv=<value
optimized out>, envp=<value optimized out>) at main.c:32
I think it might be related to the latest Xfont upgrade.
Version-Release number of selected component (if applicable):
libXfont-1.4.1-1.fc12.x86_64
xorg-x11-server-Xorg-1.7.1-7.fc12.x86_64
How reproducible:
Steps to Reproduce:
1. startx
2. do some work
3. kill X
Actual results:
Expected results:
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.
13 years, 4 months
[Bug 519317] New: AR PL UMing HK Light does not show properly in x86_64
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: AR PL UMing HK Light does not show properly in x86_64
https://bugzilla.redhat.com/show_bug.cgi?id=519317
Summary: AR PL UMing HK Light does not show properly in x86_64
Product: Fedora
Version: rawhide
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: dchen(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
chinwen_lin(a)yahoo.com
Classification: Fedora
Target Release: ---
Description of problem:
I have done two clean installs of Fedora 11, x86_64 and i386 respectively.
Both are using "Traditional Chinese" during the install process and apply the
latest update after installation.
I take a look at the font size and DPI setting on both of them and they are the
same as listed below:
應用程式字型：Sans,10
文件字型： Sans,10
桌面字型： Sans,14
視窗標題字型：Sans Bold 10
固定寬度字型：Monospace 10
解析度：96 DPI
Then I open "gucharmap" and search the character "糓" (U+7CD4).
Change the font size to 12, 11 and 10.
The i386 version works quite well.
However, the display on the x86_64 one become messy.
And the following warning message appear on the terminal:
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 12', text='糔'
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 11', text='糔'
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 9.9990234375',
text='糔'
Version-Release number of selected component (if applicable):
How reproducible:
Always in x86_64
Steps to Reproduce:
1. open "gucharmap" and
2. search the character "糔" (U+7CD4).
3. Change the font size to 12, 11 and 10.
Actual results:
Display on the x86_64 one become messy.
And the following warning message appear on the terminal:
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 12', text='糔'
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 11', text='糔'
(gucharmap:1997): Pango-WARNING **: shaping failure, expect ugly output.
shape-engine='BasicEngineFc', font='AR PL UMing HK Light 9.9990234375',
text='糔'
Expected results:
Character '糔' should be displayed properly without triggering Pango warning.
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.
13 years, 5 months
[Bug 517635] New: [ne_NP] fc-match showing "Lohit Hindi" instead of current Language
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: [ne_NP] fc-match showing "Lohit Hindi" instead of current Language
https://bugzilla.redhat.com/show_bug.cgi?id=517635
Summary: [ne_NP] fc-match showing "Lohit Hindi" instead of
current Language
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: lohit-fonts
AssignedTo: psatpute(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, pnemade(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
in Nepali Envirnment (gnome-desktop), fc-match is showing following informating
---
$echo $LANG
ne_NP.UTF-8
$fc-match
lohit_hi.ttf: "Lohit Hindi" "Regular"
---
Version-Release number of selected component (if applicable):
lohit-nepali-fonts-2.4.0-2.fc12
How reproducible:
100%
Steps to Reproduce:
1. login to Gnome-desktop with Nepali Language
2. open gnome-terminal
3. type 'fc-match'
Actual results:
lohit_hi.ttf: "Lohit Hindi" "Regular"
Expected results:
lohit_ne.ttf: "Lohit Nepali" "Regular" or something for Nepali
Additional info:
I have file /usr/share/fonts/lohit/lohit_ne.tff on system
--
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.
13 years, 5 months
[Bug 518161] New: "contains" expression seems not working on the fontconfig rule
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: "contains" expression seems not working on the fontconfig rule
https://bugzilla.redhat.com/show_bug.cgi?id=518161
Summary: "contains" expression seems not working on the
fontconfig rule
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: tagoh(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, pnemade(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Created an attachment (id=357904)
--> (https://bugzilla.redhat.com/attachment.cgi?id=357904)
sample fontconfig rule
Description of problem:
Even if the pattern contains strings that the rule specifies with "contains"
expression, it doesn't match.
Version-Release number of selected component (if applicable):
fontconfig-2.7.1-1.fc12
How reproducible:
always
Steps to Reproduce:
1.install lohit-hindi-fonts and lohit-marathi-fonts
2.put the attached rule into /etc/fonts/conf.d
3.fc-match "sans-serif:lang=mr"
4.fc-match "sans-serif:lang=mr-in"
Actual results:
3. lohit_mr.ttf: "Lohit Marathi" "Regular"
4. lohit_hi.ttf: "Lohit Hindi" "Regular"
Expected results:
the result of 3 and 4 should be:
lohit_mr.ttf: "Lohit Marathi" "Regular"
Additional info:
>From a debug log:
FcConfigSubstitute test pattern any lang Contains "mr"
FcLangSet mr-in contains mr
Missing bitmap ku-am
No match
I'm not really sure why fontconfig refers ku-am map here but apparently it
looks like fontconfig doesn't know what mr-in is.
Anyway, if no explicit lang pattern is given and applications calls
FcDefaultSubstitute(), lang will be set like mr-in from current locale
mr_IN.UTF-8 say.
--
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.
13 years, 5 months
[Bug 557862] New: Liberation Mono is not really monospaced font
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: Liberation Mono is not really monospaced font
https://bugzilla.redhat.com/show_bug.cgi?id=557862
Summary: Liberation Mono is not really monospaced font
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: liberation-fonts
AssignedTo: cchance(a)redhat.com
ReportedBy: kir(a)sacred.ru
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, cchance(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Description of problem:
When using Liberation Mono as a default monospace font in Firefox,
I have noticed that the lines of equal width (in terms of characters)
all have different width. It can clearly be seen on a screenshots that
I will attach shortly.
It took me about 15 minutes to understand it. I tried with Andale Mono and it
looks fine.
Version-Release number of selected component (if applicable):
$ rpm -q liberation-mono-fonts liberation-fonts-common fontconfig freetype
firefox fedora-release
liberation-mono-fonts-1.05.1.20090721-2.fc12.noarch
liberation-fonts-common-1.05.1.20090721-2.fc12.noarch
fontconfig-2.8.0-1.fc12.x86_64
fontconfig-2.8.0-1.fc12.i686
freetype-2.3.11-3.fc12.x86_64
freetype-2.3.11-3.fc12.i686
firefox-3.5.6-1.fc12.x86_64
fedora-release-12-2.noarch
How reproducible:
always
Steps to Reproduce:
1. make sure liberation mono is installed (rpm -q liberation-mono-fonts) and
available (fc-match 'liberation mono')
2. Open this page in your browser http://kir.sacred.ru/tmp/liberation-mono.html
3. Try increasing/decreasing text size (in case of Firefox use Ctrl with +/-).
Actual results:
Lines are of different width
Expected results:
Lines are of the same width
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.
13 years, 6 months
[Bug 557108] New: [kn_IN] ra+ ZWJ+ halanth + 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] ra+ ZWJ+ halanth + consonant is wrongly rendering
https://bugzilla.redhat.com/show_bug.cgi?id=557108
Summary: [kn_IN] ra+ ZWJ+ halanth + consonant is wrongly
rendering
Product: Fedora
Version: 12
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,
fonts-bugs(a)lists.fedoraproject.org,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Created an attachment (id=385669)
--> (https://bugzilla.redhat.com/attachment.cgi?id=385669)
Correct and wrong rendering
Description of problem:
ra+ ZWJ+ halanth + consonant is wrongly rendering
Version-Release number of selected component (if applicable):
pango-1.26.0-1.fc12
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
3.Look at the resulting glyph
Actual results:
Shown in the attachment
Expected results:
Shown in the attachment
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.
13 years, 6 months
[Bug 591559] New: Height of arrows are too low.
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: Height of arrows are too low.
https://bugzilla.redhat.com/show_bug.cgi?id=591559
Summary: Height of arrows are too low.
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: liberation-fonts
AssignedTo: cchance(a)redhat.com
ReportedBy: cchance(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, cchance(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org
Classification: Fedora
Target Release: ---
Description of problem:
(Originally from Peter Taran's email):
What do you think about moving horizontal arrows slightly up? In Courier
New arrows points almost to the middle point of small letters and it looks
nice. Liberation arrows are places essentually lower (what reason?) and
looks strange (See attachment 1).
This case is better I think (See attachment 2).
What your opinion?
--
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.
13 years, 6 months
[Bug 487581] New: Liberation Mono: incorrect spacing for Combining Diacritical Marks.
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: Liberation Mono: incorrect spacing for Combining Diacritical Marks.
https://bugzilla.redhat.com/show_bug.cgi?id=487581
Summary: Liberation Mono: incorrect spacing for Combining
Diacritical Marks.
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: liberation-fonts
AssignedTo: cchance(a)redhat.com
ReportedBy: adam.buchbinder(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: cchance(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6)
Gecko/2009020911 Ubuntu/8.10 (intrepid) Firefox/3.0.6
According to the bug on freedesktop.org (link below), Liberation Mono has an
incorrect spacing definition for "Combining Diacritical Marks"; they should
have zero space, and should render above the last letter, not the next one.
Paste following text with selected font:
Correct: accent above o
Incorrect: accent above g
Reproducible: Always
Steps to Reproduce:
1. Enter a string with a combining diacritic mark in Liberation Mono, e.g.,
"o̍g". Don't use gnome-terminal; it relies on vte, which doesn't handle
combining characters. Use something like gedit; switching fonts will reveal the
issue as the diacritical mark switches places.
Actual Results:
The diacritic appears one letter to the right of where it should be.
Expected Results:
The diacritic should appear in the proper place.
I'm using ttf-liberation 1.04.93-1 on Ubuntu Intrepid; I'm filing this as an
upstream bug. If this should be filed elsewhere, please let me know.
I'm filing this because several monospace fonts have incorrect spacing for
"Combining Diacritical Marks":
http://bugs.freedesktop.org/show_bug.cgi?id=20330
--
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.
13 years, 6 months
[Bug 540061] New: CJK text regression (w/ screenshots)
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: CJK text regression (w/ screenshots)
https://bugzilla.redhat.com/show_bug.cgi?id=540061
Summary: CJK text regression (w/ screenshots)
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: frigoris.ma(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Created an attachment (id=372855)
--> (https://bugzilla.redhat.com/attachment.cgi?id=372855)
Screenshot of XFCE4 input method setting tool. Note the coarse text
Description of problem:
I upgraded to Fedora 12 and to my surprise, some Chinese text that used to be
displayed correctly now appears to be rendered ugly and broken.
Examples can be found in the attached screenshots. All shots are taken on the
F12 system. Unfortunately I didn't take shots on the previous, working system
(because it worked as expected) so there's no comparison.
On my current F12 install the font packages are almost the same as the previous
F11 system. There are no additional fonts installed.
The installed CJK fonts are:
cjkuni-fonts-ghostscript-0.2.20080216.1-29.fc12.noarch
cjkuni-ukai-fonts-0.2.20080216.1-29.fc12.noarch
cjkuni-uming-fonts-0.2.20080216.1-29.fc12.noarch
wqy-bitmap-fonts-0.9.9-11.fc12.noarch
wqy-unibit-fonts-1.1.0-7.fc12.noarch
wqy-zenhei-fonts-0.8.38-3.fc12.noarch
xorg-x11-fonts-misc-7.2-9.fc12.noarch
I'm not sure whether this bug should be reported against this package or any of
the font packages. I really don't know. I just guessed this could possibly be a
fontconfig problem, since I didn't change the fonts.
The Appearance setting is also inherited from the previous install. The default
font used is "DejaVu Sans 9". In F11 it used to do the right thing with this
setting (displaying Western text in DejaVu Sans and render CJK text
beautifully). I didn't change anything.
Also, subpixel antialiasing seems to have stopped working for CJK text too.
Version-Release number of selected component (if applicable):
fontconfig-2.7.3-1.fc12.i686
Additional info:
I guess the cause of this issue is complex, but I have to choose a package to
report the bug against ;) If you feel it's necessary, please also inform the
font maintainers of this issue.
Thanks.
--
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.
13 years, 7 months
[Bug 485569] New: x86 fontcache can't be rebuilt on x86_64 systems
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: x86 fontcache can't be rebuilt on x86_64 systems
https://bugzilla.redhat.com/show_bug.cgi?id=485569
Summary: x86 fontcache can't be rebuilt on x86_64 systems
Product: Fedora
Version: rawhide
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: john.ellson(a)comcast.net
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Description of problem:
After various font rpm churn on rawhide my 32 bit application would crash with
a malloc failure because of a messed up font cache.
One could wonder:
a) why is the 32 bit cache different from the 64 bit?
b) why isn't fontconfig keeping them both uptodate?
but I have a simpler request:
"man fc-cache" states:
Note that fc-cache must be executed once per architecture to generate
font information customized for that architecture.
but it isn't possible to do this on x86_64 because only the 64 bit version of
/usr/bin/fc-cache is installed, even if both i386 and x86_64 fontconfig rpms
are installed.
** Request that /usr/bin/fc-cache-64 and /usr/bin/fc-cache-32 both be
installed, and that a new /usr/bin/fc-cache shell script be created that runs
them both.
The man page also says:
On a subsequent run, fc-cache will augment the cache information
files with the information for the new architecture.
but apparently this didn't work through some series of font rpm upgrades.
Version-Release number of selected component (if applicable):
fontconfig-2.6.95-1.git.66.gb162bfb.fc11
How reproducible:
100%
Steps to Reproduce:
1. cd /var/cache/fontconfig
2. rm *
3. fc-cache
Actual results:
Only *x86-64.cache-2 files created
Expected results:
Both *x86.cache-2 and *x86-64.cache-2 files created
Additional info:
Any ugly workaround to the current situation is:
rpm -e --nodeps --allmatches fontconfig fontconfig-devel
yum install fontconfig.i386
fc-cache
yum install fontconfig.x86_64 fontconfig-devel.x86_64
fc-cache
--
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.
13 years, 7 months