[Bug 1925922] New: dependency loop with harfbuzz confuses
xorg-x11-fonts-ISO8859-1-100dpi installation??
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1925922
Bug ID: 1925922
Summary: dependency loop with harfbuzz confuses
xorg-x11-fonts-ISO8859-1-100dpi installation??
Product: Fedora
Version: rawhide
Status: NEW
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: mtasaka(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,
kevin(a)tigcc.ticalc.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
Description of problem:
Comparing:
Fedora-Scientific_KDE-Live-Rawhide-20210205.n.0 [SUCCESS]
https://koji.fedoraproject.org/koji/buildinfo?buildID=1703766
Fedora-Scientific_KDE-Live-Rawhide-20210206.n.0 [FAIL]
https://koji.fedoraproject.org/koji/taskinfo?taskID=61447565
The latter one has scriptlet error:
https://kojipkgs.fedoraproject.org//work/tasks/7565/61447565/anaconda-pac...
```
08:06:12,730 INF packaging: Installed: xorg-x11-font-utils-1:7.5-48.fc34.x86_64
1611907579 2b7ebb243e1e82d3cb66c5268fc9a1d9e43b3a80385b0832bb42d2841859e4c6
08:06:12,768 INF packaging: Configuring (running scriptlet for):
xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch 1611907303
d34990ca2d30c51a49e168a636361c94eb9ec4a4995ed5724c9aab2cea71ac1f
08:06:12,789 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
```
Note that /usr/bin/mkfontscale is in xorg-x11-font-utils-1:7.5-48.fc34.x86_64 ,
which surely Requires "libfreetype.so.6()(64bit)", but freetype is not
installed when trying to run scriptlet for xorg-x11-fonts-ISO8859-1-100dpi.
Comparing the above two, I guess the change in freetype is causing this -
dependency loop between freetype and harfbuzz perhaps makes dnf to "postpone"
installation of both packages.
Version-Release number of selected component (if applicable):
xorg-x11-font-utils-1:7.5-48.fc34.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch
freetype-2.10.4-3.fc34.x86_64
harfbuzz-2.7.4-3.fc34.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 10 months
[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.
1 year, 10 months
[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.
1 year, 10 months
[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.
1 year, 11 months
[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.
1 year, 11 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
[Bug 1809989] New: By default install Noto fonts for Unicode scripts
not already covered by default
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1809989
Bug ID: 1809989
Summary: By default install Noto fonts for Unicode scripts not
already covered by default
Product: Fedora
Version: 31
Status: NEW
Component: google-noto-fonts
Assignee: petersen(a)redhat.com
Reporter: hsivonen(a)hsivonen.fi
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
i18n-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, psatpute(a)redhat.com,
pwu(a)redhat.com, tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
There is currently movement towards protecting browser users from font
fingerprinting. This means refusing, by default, to load user-installed fonts,
which makes the set of fonts that each OS installs by default even more
important than before.
Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1582687
W3C CSS WG issue:
https://github.com/w3c/csswg-drafts/issues/4497
Currently, Windows 10, macOS, Android, and Chrome OS provide broader
installed-by-default Unicode coverage than Fedora.
Examples of living scripts that have enough active users to make it to the list
at
https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scr...
but are not supported by default in Fedora 31 include Javanese, Sundanese,
Batak, Balinese, Mongolian, and New Tai Lue.
Egyptian hieroglyphs is an example of a dead script the Fedora 31 doesn't
support out of the box but Windows 10, macOS, Chrome OS, and Android do.
To remedy this with minimal disk space impact, I suggest the same approach that
Apple took. Apple bundles with macOS those Noto fonts that cover scripts that
were not already covered by the previous installed-by-default set of fonts on
macOS. In the macOS case, the on-disk footprint of the Noto fonts that were
required to take macOS to Android/Chrome OS-competitive Unicode coverage was
only a couple of megabytes. (The fonts are hidden in /Library/Application
Support/Apple/Fonts/Language Support/.) In the case of Fedora, the set of Noto
fonts required to reach the Chrome OS / Android level of script coverage is a
bit larger than in the macOS case but should still be manageable.
Please install, by default, those Noto fonts that provide support for scripts
that are not properly supported by the fonts that Fedora already installs by
default.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years