[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.
9 months
[Bug 1999078] New: Hinting broken for Bitstream Vera/DejaVu in
Epiphany
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1999078
Bug ID: 1999078
Summary: Hinting broken for Bitstream Vera/DejaVu in Epiphany
Product: Fedora
Version: 34
Status: NEW
Component: freetype
Assignee: mkasik(a)redhat.com
Reporter: ossman(a)cendio.se
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, mark(a)net-c.com,
mclasen(a)redhat.com, mkasik(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1819062
--> https://bugzilla.redhat.com/attachment.cgi?id=1819062&action=edit
Screenshot with varying sub pixel placement
Description of problem:
After upgrading from Fedora 33 to Fedora 34, there is some extremely odd
hinting bug in Epiphany. The same glyph appears with different amount of
hinting in the same line of text, causing a very odd and blurry appearance.
Version-Release number of selected component (if applicable):
freetype-2.10.4-3.fc34.x86_64
bitstream-vera-sans-fonts-1.10-41.fc33.noarch
dejavu-sans-fonts-2.37-16.fc34.noarch
epiphany-40.3-1.fc34.x86_64
webkit2gtk3-2.32.3-1.fc34.x86_64
pango-1.48.9-2.fc34.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Configure Epiphany to use Bitstream Vera or DejaVu Sans Book
2. Configure full hinting
Actual results:
Fully hinted, consistent glyphs.
Expected results:
Some glyphs are fully hinted, some look like they've been offset by a fraction
of a pixel. (See screenshot)
Additional info:
So far I'm only seeing this in Epiphany. I still filed this for freetype since
as far as I know it is freetype that does all glyph layout, hinting and
sub-pixel stuff. Feel free to move as appropriate. So it seems odd that a bug
in Epiphany can screw this up.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 months
[Bug 1895482] New: Liberation Fonts Support For Serbian locl Glyphs
Incomplete
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1895482
Bug ID: 1895482
Summary: Liberation Fonts Support For Serbian locl Glyphs
Incomplete
Product: Fedora
Version: rawhide
Hardware: x86_64
OS: Linux
Status: NEW
Component: liberation-fonts
Assignee: vishalvijayraghavan(a)gmail.com
Reporter: aleslavista(a)outlook.it
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,
petersen(a)redhat.com, psatpute(a)redhat.com,
rhughes(a)redhat.com, rstrode(a)redhat.com,
sandmann(a)redhat.com, vishalvijayraghavan(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1727218
--> https://bugzilla.redhat.com/attachment.cgi?id=1727218&action=edit
Correctly Localized Glyphs
Description of problem:
Liberation Fonts do NOT provide full support for Serbian localized glyphs.
Version-Release number of selected component (if applicable):
Liberation-Fonts 2.1-1-1
How reproducible:
You need a program that is able to access the font's localized glyphs: usually
that's LibreOffice Writer.
Steps to Reproduce:
1. Open LibreOffice Writer
2. Type бгдпт, then бгдпт in Italic, бгдпт in Bold and finally бгдпт in Italic
Bold with Liberation Serif, and do the same with Liberation Sans
3. Set the language to "Serbian Cyrillic"
Actual results:
Not all glyphs are correctly localized
Expected results:
See attachment for correctly localized glyphs
Additional info:
Liberation Mono has slanted Italic, therefore only the first glyph should be
localized: CYRILLIC LETTER SMALL BE.
--
You are receiving this mail because:
You are on the CC list for the bug.
9 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.
9 months
[Bug 1898319] New: dejavu-lgc-sans-mono-fonts: Misleading summary
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1898319
Bug ID: 1898319
Summary: dejavu-lgc-sans-mono-fonts: Misleading summary
Product: Fedora
Version: 33
Hardware: x86_64
OS: Linux
Status: NEW
Component: dejavu-fonts
Severity: low
Assignee: nicolas.mailhot(a)laposte.net
Reporter: van.de.bugger(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk,
peter(a)thecodergeek.com
Target Milestone: ---
Classification: Fedora
Description of problem:
Summary of dejavu-lgc-sans-mono-fonts is misleading. It is: "A variable-width
Latin-Greek-Cyrillic mono-space font family". Accordingly to Wikipedia:
> A monospaced font, also called a fixed-pitch, fixed-width, or non-proportional font, is a font whose letters and characters each occupy the same amount of horizontal space. This contrasts with variable-width fonts, where the letters and spacings have different widths.
So, a font is either monospaced or variable-width but not both, these are
mutually exclusive concepts. How dejavu-lgc-sans-mono-fonts can be "a
variable-width mono-space font family"??
Version-Release number of selected component (if applicable):
dejavu-lgc-sans-mono-fonts-2.37-15.fc33
How reproducible:
Always.
Steps to Reproduce:
1. $ dnf info dejavu-lgc-sans-mono-fonts
Actual results:
Summary : A variable-width Latin-Greek-Cyrillic mono-space font family
Expected results:
Summary : A Latin-Greek-Cyrillic mono-space font family
--
You are receiving this mail because:
You are on the CC list for the bug.
9 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
9 months, 3 weeks
[Bug 1813728] New: Square four dot Unicode character has incorrect
glyph
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1813728
Bug ID: 1813728
Summary: Square four dot Unicode character has incorrect glyph
Product: Fedora
Version: 31
Hardware: x86_64
OS: Linux
Status: NEW
Component: pango
Severity: low
Assignee: pwu(a)redhat.com
Reporter: guillaumepoiriermorency(a)gmail.com
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,
john.j5live(a)gmail.com, 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
Description of problem:
The glyph for the Unicode "square four dot" character is incorrect.
Version-Release number of selected component (if applicable):
I think this problem arose when upgrading from Fedora 30 to Fedora 31.
How reproducible:
The simplest way is to start GNOME Characters Map and search for "square four
dot".
--
You are receiving this mail because:
You are on the CC list for the bug.
10 months, 1 week
[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
10 months, 1 week