[Bug 507292] New: [RFE] Allow wildcards/regexps in rpm 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: [RFE] Allow wildcards/regexps in rpm deps
https://bugzilla.redhat.com/show_bug.cgi?id=507292
Summary: [RFE] Allow wildcards/regexps in rpm deps
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: rpm
AssignedTo: pmatilai(a)redhat.com
ReportedBy: nicolas.mailhot(a)laposte.net
QAContact: extras-qa(a)fedoraproject.org
CC: pmatilai(a)redhat.com, jnovy(a)redhat.com,
ffesti(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com
Classification: Fedora
(this is mostly a yum-level RFE, but it would be nice if we kept the same
depsolving logic in both apps)
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 database
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 deps like (dejavu|*|el) work in rpm
(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.
8 years, 2 months
[Bug 1195021] New: The ttf oldstandard-sfd fonts are corrupted
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1195021
Bug ID: 1195021
Summary: The ttf oldstandard-sfd fonts are corrupted
Product: Fedora
Version: 20
Component: oldstandard-sfd-fonts
Assignee: sanjay.ankur(a)gmail.com
Reporter: eko(a)lanet.lv
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
sanjay.ankur(a)gmail.com
Created attachment 994206
--> https://bugzilla.redhat.com/attachment.cgi?id=994206&action=edit
An exmple of errors in the ttf file.
Description of problem:
The ttf files are with errors.
Version-Release number of selected component (if applicable):
oldstandard-sfd-fonts-2.0.2-13.fc20
The same with oldstandard-sfd-fonts-2.0.2-15.fc21. The corrupted fonts has a
very long history – the ttf files from package
oldstandard-sfd-fonts-2.0.2-3.fc10 are already damaged.
How reproducible:
100%
Steps to Reproduce:
1. Open /usr/share/fonts/oldstandard/* files with any font viewer.
Actual results:
There is a garbage in place of letters (see the attached screen-shot)
Expected results:
Usable fonts.
Additional info:
I try to rebuilt this package from SRPM – no luck. The fontforge refuses to
built usable ttf even by hand. There are two options to solve the issue:
1) To generate OTF not the TTF (preferred solution);
2) To use ready-made ttf from
http://www.fontsquirrel.com/fonts/old-standard-TT.
--
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=0XRZ2KCY22&a=cc_unsubscribe
8 years, 5 months
[Bug 1174218] New: incorrect smoothing
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1174218
Bug ID: 1174218
Summary: incorrect smoothing
Product: Fedora
Version: 21
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: lavrinov2004(a)rambler.ru
QA Contact: extras-qa(a)fedoraproject.org
CC: behdad(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org,
kevin(a)tigcc.ticalc.org, mkasik(a)redhat.com
Description of problem:
In Fedora 21 after an upgrade, upgrade the package to version 2.5.3-13 freetype
resulting stopped working font smoothing in Mozilla Firefox and Wine. In the
previous version 2.5.3-11 freetipe everything worked well.
--
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=qPrspQ2jgn&a=cc_unsubscribe
8 years, 6 months
[Bug 1062903] New: cantarell hints very poorly with new freetype CFF engine (i.e. regression)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1062903
Bug ID: 1062903
Summary: cantarell hints very poorly with new freetype CFF
engine (i.e. regression)
Product: Fedora
Version: 20
Component: abattis-cantarell-fonts
Assignee: ccecchi(a)redhat.com
Reporter: pierre-bugzilla(a)ossman.eu
QA Contact: extras-qa(a)fedoraproject.org
CC: ccecchi(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org
Bug 995643 was filed against freetype for hinting Cantarell very poorly. That
was closed as NOTABUG. But that doesn't change the fact that Cantarell is still
fuzzy, which is a major issue for a UI font. So let's try filing this bug the
other way around. :)
Playing around with ftview suggests that forced auto hinting gives back roughly
the same hinting as in Fedora 19. So could we have that as a fontconfig bandaid
until better hinting information is available in the font itself?
--
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=y3p7SGp4NL&a=cc_unsubscribe
8 years, 6 months