[Bug 466678] New: Arial Narrow font is 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.
Summary: Arial Narrow font is inaccessible to applications
https://bugzilla.redhat.com/show_bug.cgi?id=466678
Summary: Arial Narrow font is inaccessible to applications
Product: Fedora
Version: 9
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: belegdol(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=320146)
--> (https://bugzilla.redhat.com/attachment.cgi?id=320146)
Confused gtk2 font selector
Description of problem:
Going through various bug reports, mailing list posts and so on I came to the
conclusion that applications are being currently fixed in order to support
extended fonts attibutes, and that gtk2 font selector is the one that should
work properly. Granted, it works for say DejaVu LGC condensed, but does not for
Arial Narrow (the condensed glyphs are to be found in separate files, copied
over from XP install into .fonts). fc-list outputs the following:
[jsikorski@snowball ~]$ fc-list | grep Arial
Arial
Black:style=Normalny,Normal,obyčejné,Standard,Κανονικά,Regular,Normaali,Normál,Normale,Standaard,Обычный,Normálne,Navadno,Arrunta
Arial,Arial
Narrow:style=Normalny,Narrow,Normal,obyčejné,Standard,Κανονικά,Regular,Normaali,Normál,Normale,Standaard,Обычный,Normálne,Navadno,Arrunta
Arial:style=Pogrubiona kursywa,Negreta cursiva,tučné kurzíva,fed kursiv,Fett
Kursiv,Έντονα Πλάγια,Bold Italic,Negrita Cursiva,Lihavoitu Kursivoi,Gras
Italique,Félkövér dőlt,Grassetto Corsivo,Vet Cursief,Halvfet Kursiv,Negrito
Itálico,Полужирный Курсив,Tučná kurzíva,Fet Kursiv,Kalın İtalik,Krepko
poševno,nghiêng đậm,Lodi etzana
Arial,Arial Narrow:style=Pogrubiona kursywa,Narrow,Negreta cursiva,tučné
kurzíva,fed kursiv,Fett Kursiv,Έντονα Πλάγια,Bold Italic,Negrita
Cursiva,Lihavoitu Kursivoi,Gras Italique,Félkövér dőlt,Grassetto Corsivo,Vet
Cursief,Halvfet Kursiv,Negrito Itálico,Полужирный Курсив,Tučná kurzíva,Fet
Kursiv,Kalın İtalik,Krepko poševno,Lodi etzana
Arial:style=Kursywa,Cursiva,kurzíva,kursiv,Πλάγια,Italic,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Itálico,Курсив,İtalik,Poševno,nghiêng,Etzana
Arial:style=Normalny,Normal,obyčejné,Standard,Κανονικά,Regular,Normaali,Normál,Normale,Standaard,Обычный,Normálne,Navadno,thường,Arrunta
Arial,Arial
Narrow:style=Pogrubiony,Narrow,Negreta,tučné,fed,Fett,Έντονα,Bold,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Negrito,Полужирный,Fet,Kalın,Krepko,Lodia
Arial:style=Pogrubiony,Negreta,tučné,fed,Fett,Έντονα,Bold,Negrita,Lihavoitu,Gras,Félkövér,Grassetto,Vet,Halvfet,Negrito,Полужирный,Fet,Kalın,Krepko,đậm,Lodia
Arial,Arial
Narrow:style=Kursywa,Narrow,Cursiva,kurzíva,kursiv,Πλάγια,Italic,Kursivoitu,Italique,Dőlt,Corsivo,Cursief,Itálico,Курсив,İtalik,Poševno,Etzana
[jsikorski@snowball ~]$
Gtk2 font selector gets confused and shows each of the 4 basic styles twice
(see attachment), with no visible difference whatsoever. The only application I
have found to be able to distinguish between the Narrow and normal styles is
the KDE's system settings > installed fonts thingy (also see attachment)
Version-Release number of selected component (if applicable):
fontconfig-2.5.0-2.fc9.x86_64
How reproducible:
always
Steps to Reproduce:
1. install microsoft core fonts using an rpm package
2. copy over arian{n,ni,nb,nbi}.ttf from a windows installation
3. run fc-cache
4. attempt to select one of the narrow glyphs in the font selector
Actual results:
Narrow glyphs are unavailable
Expected results:
Able to select narrow glyphs
Additional info:
Feel free to reassing this bug, I wasn't sure what to assign it to
--
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.
14 years, 1 month
[Bug 507294] New: [RFE] Allow wildcards/regexps in yum install/upgrade/comps...
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: [RFE] Allow wildcards/regexps in yum install/upgrade/comps...
https://bugzilla.redhat.com/show_bug.cgi?id=507294
Summary: [RFE] Allow wildcards/regexps in yum
install/upgrade/comps...
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: yum
AssignedTo: skvidal(a)sethdot.org
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: james.antill(a)redhat.com, pmatilai(a)redhat.com,
jnovy(a)redhat.com, tim.lauridsen(a)googlemail.com,
ffesti(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com,
skvidal(a)sethdot.org
Classification: Fedora
(this is the sister bug of ##507292 which was opened against rpm)
The problem:
Selecting a font is a multi-criterium operation. We need to match on font
family, font style, language support, unicode support, etc. At any time all of
just some of those selection criterii can be provided by the user or
applications.
To have features like font auto-installation work reliably, this matching needs
to extend to the package installation selection logic
Right now rpm is only allowing to specify atomic provides, so we can have a
font package that
Provides font(dejavusans)
and
Provides
font(:lang=el)
but there is no warranty both those provides are belonging to the same font.
There is no way to distinguish between a package that includes an actual greek
dejavusans and a package that includes a dejavusans greek-less file and another
totally different greek font
To workaround this rpm limitation we've been asking packagers to put font files
belonging to different font families in different packages. However:
1. many still don't
2. it's not technically possible for all font formats, for example the ttc font
format allows mixing of fonts with different characteristics in a single file
The ideal solution:
Ability to have Provides like:
font(comma-separated font name list|comma-separated style list|comma-separated
lang list) (rough mockup that probably needs refining)
And have package selectors like (dejavu|*|el) that work in yum
(yes a font can declare many different names, be available in many different
styles, cover many different languages)
For ttc files we'd then generate one Provides for each font included in the ttc
bundle
--
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.
14 years, 1 month
[Bug 496389] New: Incorrect Opentype Font Exporting and Printing
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: Incorrect Opentype Font Exporting and Printing
https://bugzilla.redhat.com/show_bug.cgi?id=496389
Summary: Incorrect Opentype Font Exporting and Printing
Product: Fedora
Version: rawhide
Platform: i586
OS/Version: Linux
Status: NEW
Severity: urgent
Priority: low
Component: freetype
AssignedTo: besfahbo(a)redhat.com
ReportedBy: zhoujingmiller(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, kevin(a)tigcc.ticalc.org,
fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Description of problem:
I labelled this bug as relevant to freetype for it is related to font rendering
issues in general.
This problem could be reproduced as follows:
Open an odt file, with opentype fonts specified within, with abiword and export
(print) it to pdf. Use pdffonts to list the embedded fonts within in the pdf.
Then the terminal result shows that the opentype font is replaced by times new
roman.
Open an odt file, with opentype fonts specified within, with abiword and export
(print) it to ps. Then evince fails to open the file.
Open an odt file, with opentype fonts specified within, with kword (2.0 rc1),
under gnome, and export it to pdf. Then kword crashes. However if the file is
opened via kword under kde, kword then export the file to pdf, and pdffonts
show that the pdf does include the embedded "real" opentype fonts.
Set application font to some opentype fonts and open openoffice.org writer.
Then we will notice that the openoffice.org application font is not the
opentype font specified. Also, openoffice.org cannot use opentype fonts within
the document, nor can openoffice.org display opentype fonts correctly within
the document. The document mentioned above is an odt file. I didnt notice any
other application that has such behavior.
I am also sure that this problem is reproducible on fedora 10. However, since I
am using fedora 11 rawhide right now, I filed it as a fedora 11 bug.
Version-Release number of selected component (if applicable):
freetype.i586 2.3.9-3.fc11
koffice-kword.i586 2:1.9.99.0-1.fc12
openoffice.org-writer.i586 1:3.1.0-9.2.fc11
pango.i586 1.24.1-1.fc11
pangomm.i586 2.24.0-1.fc11
qt.i586 1:4.5.0-14.fc11
abiword.i586 1:2.6.8-2.fc11
kdebase-devel.i586 6:4.2.2-2.fc11
kdelibs.i586 6:4.2.2-5.fc11
Expected results:
Abiword, Openoffice.org, Kword, and all other applications are supposed to
export documents with opentype fonts to pdf with real opentype fonts, not with
any kind of other substitution fonts, and those applications are supposed to do
so under every desktop environment.
--
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.
14 years, 1 month
[Bug 530085] New: [or_IN] - Editor's Title appearing with Underline for smc-meera-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: [or_IN] - Editor's Title appearing with Underline for smc-meera-font
https://bugzilla.redhat.com/show_bug.cgi?id=530085
Summary: [or_IN] - Editor's Title appearing with Underline for
smc-meera-font
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: aalam(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, besfahbo(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
psatpute(a)redhat.com, fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Clone Of: 526396
Created an attachment (id=365513)
--> (https://bugzilla.redhat.com/attachment.cgi?id=365513)
or_IN Screenshot with gedit, kwrite, and gnome-terminal,
Bug is clone because of Nature for Bug is same, Actually Bug for Ref is Bz
#523454
+++ This bug was initially created as a clone of Bug #526396 +++
Created an attachment (id=363117)
--> (https://bugzilla.redhat.com/attachment.cgi?id=363117)
The affected theme snapshot with meera font
Description of problem:
For any editor e.g. oowriter, gedit, when smc-meera-font is selected, its
showing underline below the Title, making the editor look ugly.
Seems a clearlooks-compact-gnome-theme bug.
Version-Release number of selected component (if applicable):
metacity-2.26.0-1.fc11.i586
How reproducible:
Always.
Steps to Reproduce:
1. Login system with malayalam locale. (ml_IN)
2. Go to System --> Preferences --> Appearance
3. Select Theme as "Clearlooks"
4. Open and Observe any editor or the theme window title itself.
Actual results:
The Underline appears on the Title Window with meera font and clearlooks
combination.
Expected results:
Underline should not appear.
--
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.
14 years, 2 months
[Bug 514158] New: [bn_IN] pango in not rendering character U+09E2 and U+09E3 due to wrong characters class assignement
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: [bn_IN] pango in not rendering character U+09E2 and U+09E3 due to wrong characters class assignement
https://bugzilla.redhat.com/show_bug.cgi?id=514158
Summary: [bn_IN] pango in not rendering character U+09E2 and
U+09E3 due to wrong characters class assignement
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: pango
AssignedTo: besfahbo(a)redhat.com
ReportedBy: psatpute(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, aalam(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
unable to see character U+09E2 and U+09E3
Version-Release number of selected component (if applicable):
pango-1.24.4-1.fc11
How reproducible:
everytime
Steps to Reproduce:
1. open gedit
2. choose ibus-rawcode type U+09E2/ U+09E3
3.
Actual results:
only dotted circle appearing
Expected results:
it should show corresponding shape in font file
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.
14 years, 2 months
[Bug 507129] New: Please update font links and deps
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: Please update font links and deps
https://bugzilla.redhat.com/show_bug.cgi?id=507129
Summary: Please update font links and deps
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mapserver
AssignedTo: cristian.balint(a)gmail.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: cristian.balint(a)gmail.com, devrim(a)gunduz.org,
fedora-fonts-bugs-list(a)redhat.com
Blocks: 473302
Classification: Fedora
Description of problem:
mapserver links to Bitstream Vera
It is a good idea to make the symlinks symlinks point to the corresponding
DejaVu (full) packages. DejaVu (full) is the most complete fork of Bitstream
Vera. It should include all the material present in Vera and its other
derivatives, plus multiple fixes. Since we install the DejaVu (full) packages
by default, dependencies on them will usually not pull in new packages on user
systems.
Version-Release number of selected component (if applicable):
0:5.4.1-1.fc12
--
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.
14 years, 2 months
[Bug 499902] New: Restructure the fontconfig settings for CJK languages
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: Restructure the fontconfig settings for CJK languages
https://bugzilla.redhat.com/show_bug.cgi?id=499902
Summary: Restructure the fontconfig settings for CJK languages
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: fangqq(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tagoh(a)redhat.com, petersen(a)redhat.com,
nicolas.mailhot(a)laposte.net, besfahbo(a)redhat.com,
fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Created an attachment (id=343146)
--> (https://bugzilla.redhat.com/attachment.cgi?id=343146)
language specific fontconfig settings for Japanese
The CJK language fontconfig settings has been a long-standing issue ever since
the beginning of using fontconfig. There hasn't been a good solution yet. The
major difficulties for causing this problem, IMO, include
1. the default 65-nonlatin.conf was badly outdated with unoptimized font orders
2. there are no CJK language-specific fontconfig files, therefore, to override
the default orders, one has to add font prefer list in the fontconfig settings
shipped with individual CJK font package.
3. because these settings were scattered into many font packages, this further
makes the problem complex, and the conflict between different CJK font packages
became more and more frequent.
To solve this issue, I propose the following solution
1. update 65-nonlatin.conf and setup an optimized and up-to-date font list
2. add language specific fontconfig settings, defining font preferred orders
with for a given lang tag, and assign these files a lower number than 65
3. remove all font order settings from all CJK related font packages
For solution step 1, I proposed a completely updated 65-nonlatin.conf at
http://bugs.freedesktop.org/show_bug.cgi?id=20911 . My rationale of the font
orders was also explained in details.
For solution step 2, I created two default settings for ja and zh locales (that
for ko can be done similarly) as examples, and you can find them in the
attachments. Because I used lang tag matching in the rules, these files can be
installed concurrently (in this sense, it is better than the language-selector
in Ubuntu, which needs to run fontconfig-voodoo to link a set of active config
under a given language).
I did the following to test this proposal. From what I saw for zh-*, ja and en
locales, all the wanted features were working properly.
Here are the details of my test:
First, I did this test with rawhide updated this morning. On the system, I
installed chinese-support and japanese-support, including wqy-bitmap-fonts,
wqy-zenhei-fonts, arphic-uming, vlgothic-fonts and some mincho Japanese font.
To clean up all the font config settings, I "su" to root, and run the following
cd /etc/fonts/conf.d/
mkdir cjk
mv *wqy* cjk
mv *vlgo* cjk
mv *arphic* cjk
mv *gothic* cjk
This is just a quick way to get rid of all the font-wise preference settings.
In the future, most of these files can stay, as long as they remove the blocks
to set <prefer> or prepend family names.
The second step is to update (of course, make a backup first) the
65-nonlatin.conf by downloading from the attachment at
http://bugs.freedesktop.org/show_bug.cgi?id=20911
Then, download the 55-language_fonts_ja-jp.conf and
55-language_fonts_zh-cn.conf from this thread and save them under
/etc/fonts/conf.d/ . This completes the settings.
For Chinese users, some of them prefer bitmap glyphs for Han characters (35%),
some prefer vectors (65%). This is controlled by installing wqy-bitmap-fonts or
uninstalling the bitmap fonts.
I tested my proposed settings for English, Japanese and Chinese languages, with
bitmap preferred settings and vector preferred settings. My screenshots for all
combination can be found at this online album:
http://picasaweb.google.com/fangqq/ProposalForFontconfigSettingsForCJKLan...
When bitmap font is installed, for en and zh desktops, fonts at sizes 9pt ~
12pt will be rendered as bitmaps for all font aliases (sans,serif, mono);
otherwise, it will be rendered by the respective vector fonts. Particularly,
for en desktop, no more font-mosaic problems caused by high priority of
Japanese fonts (such as
http://picasaweb.google.com/fangqq/ConfigScreenshot#5333302146968242258) . When
one remove the bitmap fonts, all Hanzi glyphs were rendered by the preferred
vector fonts, as expected (some remaining ones are from UMing, which I did not
disable).
For ja desktop, all fonts were rendered by their preferred vector fonts, no
matter bitmap Chinese fonts installed or not (please ignore "驿" and "阵" as they
are not defined in JIS).
I believe this approach greatly simplifies the CJK font settings by
centralizing the related settings to language specific files. All the expected
basic rendering order were achieved with the current proposed config files. Of
course one can fine-tune them further. For Korean users, a
55-language-fonts-ko.conf file can be made similarly.
It will be really great if this proposal can be tested and agreed by all CJK
font package maintainers.
--
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.
14 years, 3 months
[Bug 529594] New: Fontconfig can not pick up correct font file for 'Monospace'
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: Fontconfig can not pick up correct font file for 'Monospace'
https://bugzilla.redhat.com/show_bug.cgi?id=529594
Summary: Fontconfig can not pick up correct font file for
'Monospace'
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: fontconfig
AssignedTo: besfahbo(a)redhat.com
ReportedBy: phuang(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
Target Release: ---
Description of problem:
Fontconfig can not pick up correct font file for 'Monospace'
Version-Release number of selected component (if applicable):
fontconfig-2.7.3-1.fc12.x86_64
How reproducible:
Steps to Reproduce:
1.
2.
3.
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.
14 years, 3 months
[Bug 492510] New: Regression: wqy-bitmap-fonts preferred font over truetype 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: Regression: wqy-bitmap-fonts preferred font over truetype fonts
https://bugzilla.redhat.com/show_bug.cgi?id=492510
Summary: Regression: wqy-bitmap-fonts preferred font over
truetype fonts
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Keywords: i18n
Severity: medium
Priority: low
Component: wqy-bitmap-fonts
AssignedTo: fangqq(a)gmail.com
ReportedBy: wtogami(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: petersen(a)redhat.com, fangqq(a)gmail.com,
fedora-fonts-bugs-list(a)redhat.com,
fedora-i18n-bugs(a)redhat.com
Classification: Fedora
Target Release: ---
Failure Case 1: gramps PDF generation
=====================================
gramps is a genealogy application that generates PDF charts. It seems to ask
pango to choose fonts for it based upon given glyphs.
* In Fedora 10, it successfully output charts using entirely truetype fonts.
* In Fedora 11 however, the UTF-8 Chinese characters are rendered in PDF as
bitmap fonts, which do not scale properly and are ugly compared to the truetype
equivalents.
http://bugzilla.gnome.org/show_bug.cgi?id=576890
Behdad proposes this bug upstream, which would workaround this type of issue at
least for vector rendering cases like PDF generation. I am uncertain if this
is correct though, and it creates possibly inconsistent behavior?
Failure Case 2: pango-view
==========================
Here is a similar way to reproduce this bug:
LANG=en_US.utf8 pango-view --text "日本語 test" --font "100"
LANG=zh_CN.utf8 pango-view --text "日本語 test" --font "100"
English pango renders the Chinese characters as ugly bitmap.
Chinese pango renders the Chinese characters as truetype.
Workaround: uninstall wqy-bitmap-fonts
======================================
Both of the above problems go away if you uninstall wqy-bitmap-fonts. But this
should not be necessary.
--
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.
14 years, 3 months
