[Bug 437689] New: xorg-x11-fonts-ethiopic is not exposed correctly
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=437689
Summary: xorg-x11-fonts-ethiopic is not exposed correctly
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: xorg-x11-fonts
AssignedTo: xgl-maint(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
1. xorg-x11-fonts-ethiopic contains fonts in a modern TTF/OTF format. Those
fonts need to be exposed in /usr/share/fonts and not /usr/share/X11/fonts for
more apps to take advantage of them
2. the package contains two versions of the same font (in OTF and TTF format).
This is likely to confuse apps so either drop one or make two separate
conflicting packages so they're never installed at the same time on the same
system. The OTF file appears to be the most complete one based on its size so
I'd drop the TTF one (true all our apps do not support OTF fonts yet but they
are becoming common enough apps should be fixed and TTf versions needn't be
provided as workaround)
3. The package only contains the Goha-Tibeb Zemen font. It would be more
user-friendly if it was renamed goha-tibeb-zemen-fonts
Version-Release number of selected component (if applicable):
xorg-x11-fonts-ethiopic-7.2-6.fc9
--
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, or are watching someone who is.
14 years, 6 months
[Bug 439421] New: Hard to read arabic 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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=439421
Summary: Hard to read arabic fonts
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: fonts-arabic
AssignedTo: rbhalera(a)redhat.com
ReportedBy: swagiaal(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
The arabic font in f8 is very hard to read, I have reinstalled the package from f7.
--
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, or are watching someone who is.
14 years, 9 months
[Bug 436505] New: condensed Nimbus fonts inaccessible to applications
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=436505
Summary: condensed Nimbus fonts inaccessible to applications
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: urw-fonts
AssignedTo: than(a)redhat.com
ReportedBy: rdtennent(a)hotmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
The urw-fonts package includes four Type 1 fonts with FamilyName Nimbus Sans L
with Condensed in the FullName. But most current applications cannot deal with
Condensed, so these fonts are simply inaccessible to them. In particular,
browsers like Firefox and Konqueror do not recognize them and so web authors
have no way to specify them on web pages. This is unfortunate because these
fonts are installed on virtually every Linux system and there is no other
condensed sans font that is widely installed.
Version-Release number of selected component (if applicable):
2.4-3
How reproducible:
always
Steps to Reproduce:
1.Try to select Nimbus Sans L Condensed.
2.
3.
Actual results:
Can't be selected.
Expected results:
Can select them.
Additional info:
There seem to be three approaches to this problem. One is to insist that every
application deal with condensed/expanded fonts in the same way that they deal
with bold/italic/etc. This is a good long-term solution. A short-term solution
is to hack the fonts in question so that their FamilyName is Nimbus Sans L
Condensed; this has already been adopted by Mandriva and, apparently, Suse:
https://bugzilla.novell.com/show_bug.cgi?id=367188
Another is use fontconfig to achieve the same, as in
<match target="scan">
<test name="family" compare="eq">
<string>Nimbus Sans L</string>
</test>
<test name="width" compare="eq">
<int>75</int>
</test>
<edit name="family" mode="assign">
<string>Nimbus Sans L Condensed</string>
</edit>
</match>
or variants thereof.
I'll attach a simple html file which illustrates the problem. In any browser on
Fedora, the two lines will be in the same fonts. When the font files are
patched as suggestedb or the fontconfig snippet above installed, condensed fonts
are used for the second line.
------- Additional Comments From rdtennent(a)hotmail.com 2008-03-07 11:58 EST -------
Created an attachment (id=297217)
--> (https://bugzilla.redhat.com/attachment.cgi?id=297217&action=view)
Test file to illustrate inaccessibility of condensed fonts in browsers.
--
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, or are watching someone who is.
14 years, 9 months
[Bug 450847] New: Evince crashes in freetype
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=450847
Summary: Evince crashes in freetype
Product: Fedora
Version: 9
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: freetype
AssignedTo: besfahbo(a)redhat.com
ReportedBy: bart.vanbrabant(a)zoeloelip.be
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
When keeping evince open all the time and continuously opening pdf documents all
evince instances crash. I'm not sure of the number of document to open but it's
something between 10 and 20. I'm writing a large latex document and after every
compile the make file opens the pdf again which causes evince to reload the pdf.
Freetype turns up at the top of the backtrace so I filled it against freetype.
Version-Release number of selected component (if applicable):
cairo-1.6.4-1.fc9.x86_64
evince-2.22.2-1.fc9.x86_64
freetype-2.3.5-4.fc9.x86_64
------- Additional Comments From bart.vanbrabant(a)zoeloelip.be 2008-06-11 07:13 EST -------
Created an attachment (id=308919)
--> (https://bugzilla.redhat.com/attachment.cgi?id=308919&action=view)
Stacktrace from crash
--
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, or are watching someone who is.
14 years, 9 months
[Bug 444240] New: freetype thinks font hrger.pfa is broken
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=444240
Summary: freetype thinks font hrger.pfa is broken
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: freetype
AssignedTo: besfahbo(a)redhat.com
ReportedBy: keiths(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
The freetype library in Fedora 8 and rawhide believes that the font hrger.pfa
(and related) are broken. freetype-2.1.9-6.el4 and freetype-2.2.1-19.el5 both
work (/usr/share/fonts/default/ghostscript/hrger.pfa is identical in all cases,
from the ghostscript-fonts-5.50.x packages).
Version-Release number of selected component (if applicable):
freetype-2.3.5-3.fc8 (rawhide checked, too)
ghostscript-fonts-5.50-18.fc8
How reproducible:
100%
Steps to Reproduce:
1. gcc `freetype-config --cflags` ft.c `freetype-config --libs`
2. run resultant executable
3.
Actual results:
/usr/share/fonts/default/ghostscript/hrger.pfa: NO WORKY: error = 3
(error 3 is "broken file"/Ivalid_Format)
Expected results:
/usr/share/fonts/default/ghostscript/hrger.pfa: WORKY
Additional info:
------- Additional Comments From keiths(a)redhat.com 2008-04-25 18:34 EST -------
Created an attachment (id=303832)
--> (https://bugzilla.redhat.com/attachment.cgi?id=303832&action=view)
testcase
--
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, or are watching someone who is.
14 years, 9 months
[Bug 433559] New: Inexact font match produces different results between i386, 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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=433559
Summary: Inexact font match produces different results between
i386,x86_64
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: john.ellson(a)comcast.net
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list(a)redhat.com
Description of problem:
With dejavu and bitstream fonts installed, but freefont not installed, "fc-match
freesans" (also "fc-match sans") produces a different results on i386 than on
x86_64.
At first I thought this caused doxygen/graphviz to generate different results on
each platform which caused the file conflicts in multiarch installs. Bug
#432683. It could have been, but in this case "sans" from dejavu and bitstream
produce identical images. Its more likely that one of the build platfoms has
freefont installed, which does produce different images.
Version-Release number of selected component (if applicable):
fontconfig-2.5.0-2.fc9
How reproducible:
100%
Steps to Reproduce:
1. yum list 'dejavu*' 'bitstream*' 'freefont*'
2. fc-match freesans
3.
Actual results:
Installed Packages
bitstream-vera-fonts.noarch 1.10-8 installed
dejavu-fonts.noarch 2.23-1.fc9 installed
dejavu-fonts-experimental.noarch 2.23-1.fc9 installed
dejavu-lgc-fonts.noarch 2.23-1.fc9 installed
Available Packages
freefont.noarch 20060126-4.fc7 development
Vera.ttf: "Bitstream Vera Sans" "Roman" <<-- x86_64
DejaVuSans.ttf: "DejaVu Sans" "Book" <<-- i386
Expected results:
Same font on both architectures, given same fonts installed.
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, or are watching someone who is.
14 years, 9 months
[Bug 450709] New: fontforge can't find -ibm-courier-medium-r-normal 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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=450709
Summary: fontforge can't find -ibm-courier-medium-r-normal font
Product: Fedora
Version: 9
Platform: i386
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontforge
AssignedTo: kevin(a)tummy.com
ReportedBy: rdtennent(a)hotmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-fonts-bugs-list@redhat.com,roozbeh(a)farsiweb.info
Description of problem:
When I start up fontforge, I get the following error message:
Help! Server claimed font
-ibm-courier-medium-r-normal--26-0-0-0-m-0-iso10646-1
existed in the font list, but when I asked for it there was nothing.
I may crash soon.
Segmentation fault
I've never see this behavior before.
Version-Release number of selected component (if applicable): 20080309-1.fc9
How reproducible:
every time, on three different F9 systems
Steps to Reproduce:
1.start fontforge
2.
3.
Actual results: as above
Expected results: fontforge opens
Additional info:
% xlsfonts | grep "ibm-courier"
-ibm-courier-bold-i-normal--0-0-0-0-m-0-adobe-standard
-ibm-courier-bold-i-normal--0-0-0-0-m-0-ascii-0
-ibm-courier-bold-i-normal--0-0-0-0-m-0-iso10646-1
-ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
-ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-3
-ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-9
-ibm-courier-bold-r-normal--0-0-0-0-m-0-adobe-standard
-ibm-courier-bold-r-normal--0-0-0-0-m-0-ascii-0
-ibm-courier-bold-r-normal--0-0-0-0-m-0-iso10646-1
-ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
-ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-3
-ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-9
-ibm-courier-medium-i-normal--0-0-0-0-m-0-adobe-standard
-ibm-courier-medium-i-normal--0-0-0-0-m-0-ascii-0
-ibm-courier-medium-i-normal--0-0-0-0-m-0-iso10646-1
-ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
-ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-3
-ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-9
-ibm-courier-medium-r-normal--0-0-0-0-m-0-adobe-standard
-ibm-courier-medium-r-normal--0-0-0-0-m-0-ascii-0
-ibm-courier-medium-r-normal--0-0-0-0-m-0-iso10646-1
-ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
-ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-3
-ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-9
% fc-list "Courier 10 Pitch"
Courier 10 Pitch:style=Bold Italic
Courier 10 Pitch:style=Italic
Courier 10 Pitch:style=Regular
Courier 10 Pitch:style=Bold
--
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, or are watching someone who is.
14 years, 10 months
[Bug 444563] New: [ml_IN] When 0D2F is combined with a consonant and followed by 0D15, 0D2F joins with 0D15
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=444563
Summary: [ml_IN] When 0D2F is combined with a consonant and
followed by 0D15, 0D2F joins with 0D15
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: lohit-fonts
AssignedTo: rbhalera(a)redhat.com
ReportedBy: apeter(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: aalam@redhat.com,eng-i18n-bugs(a)redhat.com,fedora-fonts-
bugs-list@redhat.com,petersen(a)redhat.com
Description of problem:
When 0D2F is combined with a conjunct/consonant and followed by 0D15, instead of
conjunct/consonant combining with 0D2F, 0D2F gets combined with 0D15.
How reproducible:
Always
Steps to Reproduce:
1.In gedit, type 0D07, 0D28, 0D4D, 0D24,0D4D, 0D2F, 0D3E, 0D15, 0D4D, 0D15,
0D3E, 0D30, 0D4D, 200D
Actual results:
When above characters are used, when 0D28, 0D4D, 0D24,0D4D, 0D2F, 0D3E, 0D15,
0D4D, 0D15 is done, 0D2F gets combined with 0D15, 0D4D, 0D15
Expected results:
When above characters are used, when 0D28, 0D4D, 0D24,0D4D, 0D2F, 0D3E, 0D15,
0D4D, 0D15 is done, 0D28, 0D4D, 0D24 should get combined with 0D2F.
Additional info:
For ref: please see the screehshot on comment #65 on
https://bugzilla.redhat.com/show_bug.cgi?id=242016
--
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, or are watching someone who is.
14 years, 11 months
[Bug 444559] New: [ml_IN] Wrong shape of conjuncts formed using 0D30 (xRa) in a word
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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=444559
Summary: [ml_IN] Wrong shape of conjuncts formed using 0D30 (xRa)
in a word
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: lohit-fonts
AssignedTo: rbhalera(a)redhat.com
ReportedBy: apeter(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: aalam@redhat.com,eng-i18n-bugs(a)redhat.com,fedora-fonts-
bugs-list@redhat.com,petersen(a)redhat.com
Description of problem:
When conjuncts formed using 0D30 (xRa) is used in a word, the alignment is
wrong, ie, the whole word do not appear to be in one line, looks as if its in a
zig-zag shape. The vowels used with conjunct also is in wrong alignment
How reproducible:
Always
Steps to Reproduce:
1. In gedit type any consonant, say 0D2C
2. Followed by, 0D4D, 0D30, 0D3F, 0D1F, 0D4D, 0D1F, 0D28, 0D4D, 200D
Actual results:
When above steps are executed, the glyph formed using 0D2C, 0D4D, 0D30,0D3F in
the above word is not in alignment with the whole word
Expected results:
The whole word must be in a single line in same alignment and with no zig-zag shape.
Additional info:
For ref: see screenshot attached on
https://bugzilla.redhat.com/show_bug.cgi?id=242016, in comment#65
--
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, or are watching someone who is.
14 years, 11 months