[Bug 1999240] New: OpenDyslexicMono-Regular is missing
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1999240
Bug ID: 1999240
Summary: OpenDyslexicMono-Regular is missing
Product: Fedora
Version: 34
Hardware: All
OS: Linux
Status: NEW
Component: opendyslexic-fonts
Assignee: spotrh(a)gmail.com
Reporter: mikaela(a)mikaela.info
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org, spotrh(a)gmail.com
Target Milestone: ---
Classification: Fedora
Description of problem:
The package opendyslexic-fonts doesn't include the monospace variant
OpenDyslexicMono-Regular. It however exists in upstream (e.g.
https://github.com/OpenDyslexic/opendyslexic-chrome/blob/11.0.0/app/fonts...)
and Debian.
Version-Release number of selected component (if applicable):
0.600
How reproducible:
Always
Steps to Reproduce:
1. sudo dnf install opendyslexic-fonts
2. sudo updatedb
3. locate opendyslexic|grep Mono
Actual results:
The file OpenDyslexicMono-Regular.otf isn't found or visible in any font
selector.
Expected results:
/usr/share/fonts/opentype/opendyslexic/OpenDyslexicMono-Regular.otf
on Debian and I think it should appear in font lists (my Debian is headless
though).
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years
[Bug 1894757] New: update kanjistrokeorders-fonts to v4.004
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1894757
Bug ID: 1894757
Summary: update kanjistrokeorders-fonts to v4.004
Product: Fedora
Version: rawhide
Hardware: All
OS: Linux
Status: NEW
Component: kanjistrokeorders-fonts
Severity: low
Assignee: paul(a)frixxon.co.uk
Reporter: piejacker875(a)teknik.io
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
paul(a)frixxon.co.uk, rene.ribaud(a)gmail.com
Target Milestone: ---
Classification: Fedora
a new version of the font is available https://www.nihilist.org.uk/
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years
[Bug 1926533] New: Postinstall scripts are failable, fail during KDE
netinst (due to dependency loop most likely)
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1926533
Bug ID: 1926533
Summary: Postinstall scripts are failable, fail during KDE
netinst (due to dependency loop most likely)
Product: Fedora
Version: rawhide
Hardware: All
OS: All
Status: NEW
Component: xorg-x11-fonts
Severity: urgent
Assignee: xgl-maint(a)redhat.com
Reporter: awilliam(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: airlied(a)redhat.com, ajax(a)redhat.com,
caillon+fedoraproject(a)gmail.com, caolanm(a)redhat.com,
fonts-bugs(a)lists.fedoraproject.org,
jglisse(a)redhat.com, negativo17(a)gmail.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com, xgl-maint(a)redhat.com
Target Milestone: ---
Classification: Fedora
In current Fedora Rawhide, KDE network installs fail with a scriptlet error in
an xorg-x11-fonts subpackage:
16:36:01,304 INF dnf.rpm: mkfontscale: error while loading shared libraries:
libfreetype.so.6: cannot open shared object file: No such file or directory
warning: %post(xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch) scriptlet
failed, exit status 127
16:36:01,310 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package
xorg-x11-fonts-ISO8859-1-100dpi
Dependencies should be in place, AFAICT: xorg-x11-fonts subpackages require
'mkfontdir', which is in the same package as mkfontscale (xorg-x11-font-utils)
and that package requires libfreetype.so.6. What's likely happening is a
dependency loop that dnf has to break somehow. This isn't uncommon on initial
install, something like A requires B requires C requires A, and in order to do
anything, dnf has to pick *some* dependency to disregard. Probably because of
some loop like this, it's ordering install of xorg-x11-fonts-ISO8859-1-100dpi
before install of freetype, and so its %post script fails.
We could look for and try to fix that loop, but note the packaging guidelines
state:
"All scriptlets MUST exit with the zero exit status. Because RPM in its default
configuration does not execute shell scriptlets with the -e argument to the
shell, excluding explicit exit calls (frowned upon with a non-zero argument!),
the exit status of the last command in a scriptlet determines its exit status.
Most commands in the snippets in this document have a “|| :” appended to them,
which is a generic trick to force the zero exit status for those commands
whether they worked or not. Usually the most important bit is to apply this to
the last command executed in a scriptlet, or to add a separate command such as
plain “:” or “exit 0” as the last one in a scriptlet. Note that depending on
the case, other error checking/prevention measures may be more appropriate.
Non-zero exit codes from scriptlets can break installs/upgrades/erases such
that no further actions will be taken for that package in a transaction (see
Ordering), which may for example prevent an old version of a package from being
erased on upgrades, leaving behind duplicate rpmdb entries and possibly stale,
unowned files on the filesystem. There are some cases where letting the
transaction to proceed when some things in scriptlets failed may result in
partially broken setup. It is however often limited to that package only
whereas letting a transaction to proceed with some packages dropped out on the
fly is more likely to result in broader system wide problems."
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy...
basically, by policy scriptlets should be written to return 0 even if they
don't work. These scriptlets aren't respecting that. Given that not running
mkfontdir likely doesn't have any calamitous consequences, I think it would
make sense to go with the guidelines and amend all the scriptlets to add `|| :`
at the end (which will cause them to exit 0 even if the command failed).
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 1 month
[Bug 2001332] New: pango-view with --backend=ft2 and
---antialias=none generates antialiased renderings
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2001332
Bug ID: 2001332
Summary: pango-view with --backend=ft2 and ---antialias=none
generates antialiased renderings
Product: Fedora
Version: 34
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: high
Assignee: pwu(a)redhat.com
Reporter: andre.maute(a)gmx.de
QA Contact: extras-qa(a)fedoraproject.org
CC: caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com,
pwu(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1820649
--> https://bugzilla.redhat.com/attachment.cgi?id=1820649&action=edit
image showing the problem
Description of problem:
Hello Fedora Team,
I have a recently updated Fedora 34 installation.
The problem I want to report is that it looks like
the pango-view tool is always turning antialiasing on
when one uses the FreeType backend --backend=ft2,
even when one explicitly switches antialiasing off with --antialias=none,
whereas it works for the --backend=cairo option.
A second question would be if the FreeType backend
generally doesn't/can't support --antialias=none?
I tried to find some examples in C with antialising turned off
but I wasn't successful.
I must confess I didn't check other distributions.
As pango-view is regarded as a tool for creating minimal reproducers
against the font rendering stack, I dare to set the severity to 'high' :-)
Best Regards
Andre
Version-Release number of selected component (if applicable):
$ uname -a
Linux localhost.localdomain 5.13.13-200.fc34.x86_64 #1 SMP Thu Aug 26 17:06:39
UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ dnf list installed | grep dejavu
dejavu-lgc-sans-fonts.noarch 2.37-16.fc34
@fedora
dejavu-lgc-sans-mono-fonts.noarch 2.37-16.fc34
@fedora
dejavu-lgc-serif-fonts.noarch 2.37-16.fc34
@fedora
dejavu-sans-fonts.noarch 2.37-16.fc34
@fedora
dejavu-sans-mono-fonts.noarch 2.37-16.fc34
@fedora
dejavu-serif-fonts.noarch 2.37-16.fc34
@fedora
$ dnf list installed | grep ImageMagick
ImageMagick.x86_64 1:6.9.11.27-3.fc34
@fedora
ImageMagick-libs.x86_64 1:6.9.11.27-3.fc34
@fedora
$ dnf list installed | grep pango
pango.i686 1.48.9-2.fc34
@updates
pango.x86_64 1.48.9-2.fc34
@updates
pango-devel.x86_64 1.48.9-2.fc34
@updates
pangomm.x86_64 2.46.1-1.fc34
@updates
$ dnf list installed | grep freetype
freetype.i686 2.10.4-3.fc34
@fedora
freetype.x86_64 2.10.4-3.fc34
@fedora
freetype-devel.x86_64 2.10.4-3.fc34
@fedora
$ dnf list installed | grep fontconfig
fontconfig.i686 2.13.94-2.fc34
@updates
fontconfig.x86_64 2.13.94-2.fc34
@updates
fontconfig-devel.x86_64 2.13.94-2.fc34
@updates
$ dnf list installed | grep cairo
cairo.i686 1.17.4-3.fc34
@fedora
cairo.x86_64 1.17.4-3.fc34
@fedora
cairo-devel.x86_64 1.17.4-3.fc34
@fedora
cairo-gobject.i686 1.17.4-3.fc34
@fedora
cairo-gobject.x86_64 1.17.4-3.fc34
@fedora
cairomm.x86_64 1.14.2-8.fc34
@fedora
python2-cairo.x86_64 1.18.2-8.fc34
@fedora
python3-cairo.x86_64 1.20.0-2.fc34
@fedora
How reproducible:
Always
Steps to Reproduce:
$ pango-view --no-display --dpi=72 --backend=cairo --antialias=none
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-cairo-aa-none.png
$ pango-view --no-display --dpi=72 --backend=cairo --antialias=gray
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-cairo-aa-gray.png
$ pango-view --no-display --dpi=72 --backend=cairo --antialias=subpixel
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-cairo-aa-subpixel.png
$ pango-view --no-display --dpi=72 --backend=ft2 --antialias=none
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-ft2-aa-none.png
$ pango-view --no-display --dpi=72 --backend=ft2 --antialias=gray
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-ft2-aa-gray.png
$ pango-view --no-display --dpi=72 --backend=ft2 --antialias=subpixel
--font="DejaVu Sans 38" --text="ABCDEFGHIJKLMNOPQRSTUVWXYZ"
--output=abc-ft2-aa-subpixel.png
$ gimp abc-*.png
Actual results:
Attached pngs.
The file abc-ft2-aa-none.png is in gray-scale and not as expected in
black-white.
The file abc-cairo-aa-none.png is in black-white as expected.
Expected results:
I would have expected the files abc*--aa-none.png looking near identical.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 1 month
[Bug 2070686] New: freetype-2.12.0 is available
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2070686
Bug ID: 2070686
Summary: freetype-2.12.0 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: freetype
Keywords: FutureFeature, Triaged
Assignee: mkasik(a)redhat.com
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org, mclasen(a)redhat.com,
mkasik(a)redhat.com, rhughes(a)redhat.com,
rstrode(a)redhat.com, sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Latest upstream release: 2.12.0
Current version/release in rawhide: 2.11.1-2.fc36
URL: https://www.freetype.org/
Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
Based on the information from Anitya:
https://release-monitoring.org/project/854/
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2070686
2 years, 2 months
[Bug 2021366] New: Nimbus Mono PS font should not fc-match Courier,
as certain letter combinations are not monospaced
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2021366
Bug ID: 2021366
Summary: Nimbus Mono PS font should not fc-match Courier, as
certain letter combinations are not monospaced
Product: Fedora
Version: 35
Hardware: x86_64
OS: Linux
Status: NEW
Component: Fonts
Assignee: i18n-bugs(a)lists.fedoraproject.org
Reporter: info(a)skierpage.com
QA Contact: fonts-bugs(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Created attachment 1840789
--> https://bugzilla.redhat.com/attachment.cgi?id=1840789&action=edit
look at "affiliation"
Description of problem:
I visited https://schema.org/Person in Firefox in Fedora 35 KDE spin and
noticed the monospace text "affiliation" was not monospaced; the letters "ffi"
were on top of each other as if replaced by the ligature ffi.
The page CSS is styling the <code> tag "font-family: Courier, monospace;", and
in Fedora 35 KDE Spin `fc-match Courier` returns
NimbusMonoPS-Regular.otf: "Nimbus Mono PS" "Regular"
indeed, if I set font-family to "Nimbus Mono PS" in some simple HTML
https://www.skierpage.com/bugs/nimbusmono_not_monospaced.html , other ff
combinations are also "ligature-ized".
I tried these two URLs in the chromium-browser package and in the Epiphany and
Konqueror browser flatpaks. These did not use "Nimbus Mono PS" as the fallback
font for font-family "Courier" so did not display "affiliation" badly on the
Person web page, but if you specify font-family "Nimbus Mono PS", you get the
ligature.
Version-Release number of selected component (if applicable):
Mozilla Firefox 94.0
urw-base35-fonts-20200910-9.fc35.src.rpm
How reproducible:
Always.
Steps to Reproduce:
1. Visit https://schema.org/Person and
https://www.skierpage.com/bugs/nimbusmono_not_monospaced.html in Firefox and
other browsers.
2. Note how "ffi" appears.
Actual results:
Firefox uses "Nimbus Mono PS" as the fallback for font-family Courier; all
these browsers replace "ffi" and such with the ligature character in "Nimbus
Mono PS", destroying the desired monospace effect.
Expected results:
Monospaced fonts should appear... monospaced, so every character should occupy
the same amount of horizontal space. However, if a font provides ligature
glyphs for "ffi" and such, then it's unclear if it's wrong for the browser to
use them; (l33t developers now explicitly use monospaced coding fonts that do
wacky substitutions.)
So the fix could be for Firefox and/or fc-match to _not_ use Nimbus Mono PS
when text handling requests Courier. The other browsers on my system don't,
I'm not sure why. Another could be to remove the ligatures from Nimbus Mono PS.
Additional info:
The rendering of code on that page (see attachment) is pretty terrible, note
the oversized 'd's in "address". Another reason to have Courier match some
other monospaced font than Nimbus Mono PS.
You can use the Fontmatrix program to enable OpenType features; checking latn >
dflt > liga changes the display of "ff" combinations.
Firefox using ligatures in monospaced fonts is
https://bugzilla.mozilla.org/show_bug.cgi?id=384395 , was closed WONTFIX "We
can't really do anything about it -- the underlying text system is doing the
ligaturization, not us".
ArchLinux users discussed the problem in
https://bbs.archlinux.org/viewtopic.php?id=238832
--
You are receiving this mail because:
You are the QA Contact for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2021366
2 years, 2 months
[Bug 2045012] New: Split the Cantarell fonts into 2 for VF and
non-variable fonts
by bugzilla@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2045012
Bug ID: 2045012
Summary: Split the Cantarell fonts into 2 for VF and
non-variable fonts
Product: Fedora
Version: rawhide
Status: NEW
Component: abattis-cantarell-fonts
Assignee: klember(a)redhat.com
Reporter: petersen(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: cosimo.cecchi(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
klember(a)redhat.com, me(a)fale.io, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Matthias Clasen pointed out that abattis-cantarell-fonts currently
includes both variable and non-variable fonts.
This duplication makes it harder for pango to choose the right font for
example.
We should split the binary package into two and only install the VF one by
default.
Version-Release number of selected component (if applicable):
abattis-cantarell-fonts-0.301-6
Steps to Reproduce:
1. rpm -ql abattis-cantarell-fonts
Actual results:
Contains both fixed and variable fonts
Expected results:
Probably Cantarell-VF.otf should be moved to abattis-cantarell-vf-fonts
subpackage
and made the default.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2045012
2 years, 2 months