[Bug 1853937] New: Inconsistent rendering of ti, tt ligatures
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1853937
Bug ID: 1853937
Summary: Inconsistent rendering of ti, tt ligatures
Product: Fedora
Version: 32
Status: NEW
Component: lato-fonts
Assignee: pikachu.2014(a)gmail.com
Reporter: james(a)ettle.org.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
pikachu.2014(a)gmail.com, piotr1212(a)gmail.com
Target Milestone: ---
Classification: Fedora
Created attachment 1699956
--> https://bugzilla.redhat.com/attachment.cgi?id=1699956&action=edit
Sample renderings
The horizontal 't-crossing' strokes of the ti and tt ligatures are rendered
slightly below the x-height, in a manner that is more- or less-visible
depending on font size. It's most visible at 11pt.
Attached are samples rendered with RGB subpixel anti-aliasing, slight hinting.
The issue is visible in the 8, 11 and 14pt samples.
lato-fonts-2.015-9.fc32.noarch
freetype-2.10.1-2.fc32.x86_64
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 6 months
[Bug 1786596] New: Vertical alignment is off with PANGO_GRAVITY_EAST
and PANGO_GRAVITY_HINT_LINE
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1786596
Bug ID: 1786596
Summary: Vertical alignment is off with PANGO_GRAVITY_EAST and
PANGO_GRAVITY_HINT_LINE
Product: Fedora
Version: 31
OS: Linux
Status: NEW
Component: pango
Assignee: pwu(a)redhat.com
Reporter: abetakehiko(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:
Japanese chars and Latin chars in the same line do not vertically align when
the pango context's gravity is set to PANGO_GRAVITY_EAST and its hint set to
PANGO_GRAVITY_HINT_LINE.
Version-Release number of selected component (if applicable):
pango-1.44.7-1.fc31.x86_64
How reproducible:
Always
Steps to Reproduce:
pango-view --text="あーいうえお abcde" --gravity east --gravity-hint line
--font="NotoSerifJP 24"
Actual results:
Japanese chars and Latin chars in the same line do not vertically align.
Expected results:
Japanese chars and Latin chars in the same line vertically align as before.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 7 months
[Bug 1953087] New: fonttools: please also provide woff functionality
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1953087
Bug ID: 1953087
Summary: fonttools: please also provide woff functionality
Product: Fedora
Version: rawhide
Status: NEW
Component: fonttools
Assignee: pnemade(a)redhat.com
Reporter: fschwarz(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
pnemade(a)redhat.com, sshedmak(a)redhat.com,
tagoh(a)redhat.com
Target Milestone: ---
Classification: Fedora
The upcoming WeasyPrint 53 will require "python3dist(fonttools[woff]) >= 4" and
it seems as if Fedora does not provide that extra.
Upgrading WeasyPrint to version 53 will be a plus for Fedora users as that
version will not use cairo anymore. The problem with cairo is that version 1.17
changed font rendering so WeasyPrint tests are sometimes failing. WeasyPrint
upstream will not spend any time on these issues as they are planning to
migrate away from cairo.
Ideally we could have woff functionality in F34 + rawhide (both are using cairo
1.17).
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 8 months
[Bug 1752788] New: CVE-2015-9381 freetype: a heap-based buffer
over-read in T1_Get_Private_Dict in type1/t1parse.c leading to information
disclosure
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1752788
Bug ID: 1752788
Summary: CVE-2015-9381 freetype: a heap-based buffer over-read
in T1_Get_Private_Dict in type1/t1parse.c leading to
information disclosure
Product: Security Response
Hardware: All
OS: Linux
Status: NEW
Component: vulnerability
Keywords: Security
Severity: medium
Priority: medium
Assignee: security-response-team(a)redhat.com
Reporter: mrehak(a)redhat.com
CC: ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org,
gnome-sig(a)lists.fedoraproject.org,
john.j5live(a)gmail.com, 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: Other
FreeType before 2.6.1 has a heap-based buffer over-read in T1_Get_Private_Dict
in type1/t1parse.c.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1774474] New: Missing some coverage in certain variants
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1774474
Bug ID: 1774474
Summary: Missing some coverage in certain variants
Product: Fedora
Version: rawhide
Status: NEW
Component: dejavu-fonts
Severity: low
Assignee: nicolas.mailhot(a)laposte.net
Reporter: tagoh(a)redhat.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:
I'm expecting to see same glyph coverage to all variants available in the
package but apparently not. this is just a result running some test cases with
fc-validate against languages which is expectedly or unexpectedly supposed to
assign dejavu as a default font for.
See logs stored in the following link for more details. that demonstrates this
issue.
https://jenkins-continuous-infra.apps.ci.centos.org/blue/rest/organizatio...
Version-Release number of selected component (if applicable):
2.37-2.fc31
How reproducible:
always
Steps to Reproduce:
1.fc-validate -l <lang> /path/to/fonts
2.
3.
Actual results:
(One of) snippet from logs:
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSans-Bold.ttf satisfy ab language coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSans.ttf satisfy ab language coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSansCondensed-Oblique.ttf satisfy ab language
coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf satisfy ab language coverage.
[2019-11-19T14:20:10.928Z] RESULT: FAIL:
/usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf doesn't satisfy ab language
coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSansCondensed-Bold.ttf satisfy ab language
coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSansCondensed-BoldOblique.ttf satisfy ab language
coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSansCondensed.ttf satisfy ab language coverage.
[2019-11-19T14:20:10.928Z] RESULT: PASS:
/usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf satisfy ab language
coverage.
[2019-11-19T14:20:10.928Z] Run test ab: done. Test's exit code: 0
Expected results:
ExtraLight should have same coverage.
Additional info:
As it is an experimental, this may be an RFE.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1860412] New: New version of Droid Sans causes problems in
Firefox and Thunderbird GUIs
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1860412
Bug ID: 1860412
Summary: New version of Droid Sans causes problems in Firefox
and Thunderbird GUIs
Product: Fedora
Version: 32
Status: NEW
Component: google-droid-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: skontar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
nicolas.mailhot(a)laposte.net, oliver(a)redhat.com,
paul(a)frixxon.co.uk, tremble(a)tremble.org.uk
Target Milestone: ---
Classification: Fedora
Description of problem:
For years I am using Droid Sans 11 as my GUI font in my desktop. With recent
update the text in Firefox and Thunderbird gained weird padding, causing wasted
space, weird alignment issues, sometimes slight text cut-off at bottom
(Thunderbird).
Version-Release number of selected component (if applicable):
google-droid-sans-fonts-20200215-3.fc32.noarch
Last good: google-droid-sans-fonts-20120715-16.fc31.noarch
How reproducible:
Set Droid Sans 11 (also different size) as a GUI font. See how menus and parts
of GUI looks like, overlaps and behaves. Compare by testing old version of the
package, or different font such as Roboto.
Steps to Reproduce:
1. Install google-droid-sans-fonts-20200215-3.fc32.noarch
2. Set Droid Sans 11 as default a GUI font
3. Open Thunderbird or Firefox
Actual results:
Weird unnecesarry padding in menus, cut-offs and similar text issues.
Expected results:
No change when compared to old version.
Additional info:
Reproducible in clean XFCE spin VM. Easily fixed by using similar font (Roboto)
or old version of the package, so the problem is in the font package.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1839471] New: OpenType variant of Lucida Typewriter has extra
spacing around characters
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1839471
Bug ID: 1839471
Summary: OpenType variant of Lucida Typewriter has extra
spacing around characters
Product: Fedora
Version: 32
Status: NEW
Component: bitmap-fonts
Assignee: psatpute(a)redhat.com
Reporter: tsmetana(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: fonts-bugs(a)lists.fedoraproject.org,
petersen(a)redhat.com, pnemade(a)redhat.com,
psatpute(a)redhat.com, pwu(a)redhat.com
Target Milestone: ---
Classification: Fedora
Created attachment 1691497
--> https://bugzilla.redhat.com/attachment.cgi?id=1691497&action=edit
Screenshot of the terminal in Fedora 32
Description of problem:
The OpenType version of Lucida Typewriter fonts has extra spacing around every
character making it quite unusable.
Version-Release number of selected component (if applicable):
bitmap-lucida-typewriter-opentype-fonts-0.3-33.fc32
xfce4-terminal-0.8.9.1-2.fc32
How reproducible:
Always
Steps to Reproduce:
1. Install bitmap-lucida-typewriter-opentype-fonts
2. Select the "LucidaTypewriter Sans" for the termina font
Actual results:
There's extra spacing around the characters.
Expected results:
The font looks the same as on Fedora 30
Additional info:
I assume the automatic conversion from the PCF fonts doesn't work completely
well. It's definitely better than in F31 (see bug #1767384) but not good yet.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1836987] New: Font descent miscalculated for some applications
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1836987
Bug ID: 1836987
Summary: Font descent miscalculated for some applications
Product: Fedora
Version: 32
Status: NEW
Component: dejavu-fonts
Assignee: nicolas.mailhot(a)laposte.net
Reporter: mcrha(a)redhat.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
Created attachment 1689621
--> https://bugzilla.redhat.com/attachment.cgi?id=1689621&action=edit
See the letters like 'j', 'g', 'y', which are cut
When I install hexchat (hexchat-2.14.3-3.fc32.x86_64) it has preselected in
Settings->Preferences font "Monospace 9". It seems to be mapped to Dejavu font
in Fedora 32, according to:
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Regular"
I have installed dejavu-sans-mono-fonts-2.37-7.fc32.noarch and the font in
hexchat has cut the text vertically, the bottom part of the line, some part
below the base line, is missing.
I guess it's due to misreported descent for the font, possibly some fraction,
which, when recalculated to pixels, rounds down, causing the pixel cut. This is
even more problematic for an underscore ('_'), which is not visible at all,
because it's at the very bottom of the font height, thus it looks like a space,
not underscore.
I see this in more applications, not only with hexchat, thus it might not be a
problem in there.
I also see this with other fonts, like with:
VeraMono.ttf: "Bitstream Vera Sans Mono" "Regular"
thus, maybe, it's even lower in the stack.
I worked around this in my editor by adding one pixel to
pango_font_metrics_get_descent() / PANGO_SCALE
but it's only a workaround.
I've also Fedora 30 machine and it has installed:
dejavu-sans-mono-fonts-2.37-1.fc30.noarch
and the hexchat shows lines properly. It also says:
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
I've also a Fedora 31 machine, which has installed:
dejavu-sans-mono-fonts-2.37-2.fc31.noarch
and hexchat is similarly broken as in Fedora 32. It says:
$ fc-match monospace
DejaVuSansMono.ttf: "DejaVu Sans Mono" "Book"
Looking in the package history in koji, there was not done any real change
between 2.37-1 and 2.37-2.
Thus, maybe, it is nothing new.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1813230] New: [RFE] ghostscript add support for variable fonts
from fontconfig
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1813230
Bug ID: 1813230
Summary: [RFE] ghostscript add support for variable fonts from
fontconfig
Product: Red Hat Enterprise Linux 8
Version: 8.4
Status: NEW
Component: ghostscript
Assignee: zdohnal(a)redhat.com
Reporter: zdohnal(a)redhat.com
QA Contact: qe-baseos-daemons(a)redhat.com
CC: cosimo.cecchi(a)gmail.com, dkaspar(a)redhat.com,
extras-qa(a)fedoraproject.org,
fonts-bugs(a)lists.fedoraproject.org, ian(a)ianweller.org,
jsteiner(a)redhat.com, klember(a)redhat.com, me(a)fale.io,
mosvald(a)redhat.com, tagoh(a)redhat.com,
twaugh(a)redhat.com, zdohnal(a)redhat.com
Depends On: 1813187
Target Milestone: rc
Classification: Red Hat
Pool ID: sst_cs_infra_services_rhel_8
+++ This bug was initially created as a clone of Bug #1813187 +++
Description of problem:
During investigating https://bugzilla.redhat.com/show_bug.cgi?id=1722900 was
found the font mentioned in summary fails with mismatch on
FcPatternGetInteger() from fontconfig when gs asks for FC_WEIGHT value.
I'm not sure whether the font or fontconfig is at fault, so I'm filing the
issue on font package.
I'm willing to help with debug, if needed.
Version-Release number of selected component (if applicable):
abattis-cantarell-fonts-0:0.201-2.fc32.noarch
fontconfig-2.13.92-6.fc32.x86_64
ghostscript-9.50-1.fc32
Steps to Reproduce:
1. gs -dNODISPLAY -dBATCH nasmdoc.ps
Actual results:
You can see in logs a message:
DEBUG: FC_WEIGHT didn't match in /usr/share/fonts/cantarell/Cantarell-VF.otf
Expected results:
No such message
Additional info:
--- Additional comment from Kalev Lember on 2020-03-13 08:32:41 UTC ---
Sorry, I don't know much about fonts and don't think I can be of much help
debugging this. Can you ask Jakub and/or Tagoh if they know what's going on
(CCd)?
--- Additional comment from Nicolas Mailhot on 2020-03-13 08:42:52 UTC ---
On the fontconfig side, that’s basically bug
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/222
No idea if gs also contains problematic weight assumptions, invalidated by the
introduction of variable fonts.
On the packaging side cantarell has probably not been converted to new font
packaging guidelines yet. It needs some name fixing (use of a space-free
ExtraBold qualifier, removal of Regular in Name ID 4 for the Regular face,
making NameID 4 consistent with Name ID 17 for other faces). Though except for
the ExtraBold part, everything else will going to be workarounded in future
fontconfig versions.
--- Additional comment from Nicolas Mailhot on 2020-03-13 08:52:38 UTC ---
(Also fontconfig exposes a generic meta face for variable fonts, this face does
not have any specific weight, it gives the weight scale for the whole family)
--- Additional comment from Akira TAGOH on 2020-03-13 08:58:05 UTC ---
That isn't related to this.
I don't know how ghostscript collects fonts from fontconfig though (probably
using FcFontList()?), the problem here would be that they have dealt with a
meta face as a normal face which has true in FC_VARIABLE and contains a weight
in range but not integer.
That's not a bug in font nor fontconfig.
--- Additional comment from Zdenek Dohnal on 2020-03-13 09:25:03 UTC ---
Hi Akira,
yes, you're right, gs uses FcFontlist() - does the following to get font list:
-----------------------------------------------------
/* load the font set that we'll iterate over */
pat = FcPatternBuild(NULL,
FC_OUTLINE, FcTypeBool, 1,
FC_SCALABLE, FcTypeBool, 1,
NULL);
os = FcObjectSetBuild(FC_FILE, FC_OUTLINE,
FC_FAMILY, FC_WEIGHT, FC_SLANT,
NULL);
state->font_list = FcFontList(0, pat, os);
-----------------------------------------------------
then when it enumerates the fonts it calls (f.e. for FC_WEIGHT):
result = FcPatternGetInteger (font, FC_WEIGHT, 0, &weight_fc);
(similar thing for FC_FILE, FC_FAMILY, FC_SLANT, FC_OUTLINE).
Would you mind telling me/pointing me to a manual how to deal with it
correctly, if it is not a problem of font/fontconfig?
--- Additional comment from Akira TAGOH on 2020-03-13 10:07:42 UTC ---
If ghostscript has no plans to support variable fonts or a plan to support only
named-instances, you can set false to FC_VARIABLE
as a query pattern; that should be more simple and easier than your patch
applied in ghostscript; you can take care of the named-instances in VF font
files as same as usual face then. otherwise set FcDontCare to FC_VARIABLE and
need more changes in the code to deal with non-named-instances perhaps.
The meta face which you faced the issue this time provides such information
instead of providing it as one of faces because there are so many patterns to
enummerate everything and quite hard to do. the targetted properties such as
FC_WEIGHT, FC_WIDTH and FC_SIZE has a value in FcRange which means they can use
an unique value between them.
Unfortunately there are no more detailed document though, pango source code may
helps how to deal with them.
--- Additional comment from Akira TAGOH on 2020-03-13 10:16:22 UTC ---
You can see what values the meta face provides. try fc-list -b -v
Cantarell:variable=true for example.
--- Additional comment from Zdenek Dohnal on 2020-03-13 10:40:41 UTC ---
IMO they are not aware of the fact the variable fonts need a special care when
are used from fontconfig.
I'll check with upstream about variable fonts then.
Thank you for the info!
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1813187
[Bug 1813187] ghostscript does not load variable fonts from fontconfig
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months
[Bug 1813187] New: Cantarell-VF.otf fails on fontconfig's
FcPatternGetInteger() call for FC_WEIGHT
by bugzilla＠redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=1813187
Bug ID: 1813187
Summary: Cantarell-VF.otf fails on fontconfig's
FcPatternGetInteger() call for FC_WEIGHT
Product: Fedora
Version: 32
Status: NEW
Component: abattis-cantarell-fonts
Assignee: klember(a)redhat.com
Reporter: zdohnal(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: cosimo.cecchi(a)gmail.com,
fonts-bugs(a)lists.fedoraproject.org, ian(a)ianweller.org,
klember(a)redhat.com, me(a)fale.io
Target Milestone: ---
Classification: Fedora
Description of problem:
During investigating https://bugzilla.redhat.com/show_bug.cgi?id=1722900 was
found the font mentioned in summary fails with mismatch on
FcPatternGetInteger() from fontconfig when gs asks for FC_WEIGHT value.
I'm not sure whether the font or fontconfig is at fault, so I'm filing the
issue on font package.
I'm willing to help with debug, if needed.
Version-Release number of selected component (if applicable):
abattis-cantarell-fonts-0:0.201-2.fc32.noarch
fontconfig-2.13.92-6.fc32.x86_64
ghostscript-9.50-1.fc32
Steps to Reproduce:
1. gs -dNODISPLAY -dBATCH nasmdoc.ps
Actual results:
You can see in logs a message:
DEBUG: FC_WEIGHT didn't match in /usr/share/fonts/cantarell/Cantarell-VF.otf
Expected results:
No such message
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 10 months