fonts-bugs May 2020

fonts-bugs@lists.fedoraproject.org

1 participants
109 discussions

[Bug 1820166] New: Droid sans overrides my default CJK font
by bugzilla＠redhat.com 28 Jan '22

28 Jan '22

https://bugzilla.redhat.com/show_bug.cgi?id=1820166 Bug ID: 1820166 Summary: Droid sans overrides my default CJK font Product: Fedora Version: 32 Status: NEW Component: google-droid-fonts Severity: low Assignee: nicolas.mailhot(a)laposte.net Reporter: taocrismon(a)hotmail.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: I have this (per-user) fontconfig configuration to set my preferred sans-serif font: <alias> <family>sans-serif</family> <prefer> <family>Noto Sans</family> <family>Noto Sans CJK SC</family> </prefer> </alias> It should fall back to "Noto Sans CJK SC" when displaying CJK characters. Since F32 this isn't working anymore. CJK characters are rendered in a different font, which I cannot recognize. Digging through fc_debug logs, "Droid Sans" is appended right after "Noto Sans", before "Noto Sans CJK SC" in the font matching list. Debug messages confirm it's indeed Droid Sans getting picked. Removing the relevant part in /etc/fonts/conf.d/65-google-droid-sans-fonts.conf mitigates this issue. However since both Noto Sans & Droid Sans do not contain CJK characters, they should both be skipped in favor of CJK fonts. Could this be a metadata problem? i.e. Droid Sans wrongly advertises as CJK capable. Version-Release number of selected component (if applicable): google-droid-sans-fonts-20200215-3.fc32.noarch -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1753020] New: Powerline symbols no longer align
by bugzilla＠redhat.com 30 Nov '21

30 Nov '21

https://bugzilla.redhat.com/show_bug.cgi?id=1753020 Bug ID: 1753020 Summary: Powerline symbols no longer align Product: Fedora Version: 30 Status: NEW Component: terminus-font Assignee: extras-orphan(a)fedoraproject.org Reporter: andrew(a)linuxjedi.co.uk QA Contact: extras-qa(a)fedoraproject.org CC: extras-orphan(a)fedoraproject.org, fonts-bugs(a)lists.fedoraproject.org, rhbugs(a)n-dimensional.de Target Milestone: --- Classification: Fedora Created attachment 1615993 --> https://bugzilla.redhat.com/attachment.cgi?id=1615993&action=edit Screenshot of zsh+om-my-zsh using powerline-fonts and terminus-fonts 4.48 Description of problem: With version 4.48 of the Terminus font the powerline symbols no longer align for sizes less than 14pt Version-Release number of selected component (if applicable): terminus-fonts-4.48-1.fc30.noarch How reproducible: 100% Steps to Reproduce: 1. Install terminus-fonts and powerline-fonts. 2. Use something with powerline (zsh, vim, etc...) 3. Update to the latest terminus-fonts version 4. Use powerline things again Actual results: Bad symbol alignment Expected results: Good symbol alignment Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 17

[Bug 1786596] New: Vertical alignment is off with PANGO_GRAVITY_EAST and PANGO_GRAVITY_HINT_LINE
by bugzilla＠redhat.com 26 Aug '21

26 Aug '21

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.

1 6

[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 02 Jun '21

02 Jun '21

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.

1 13

[Bug 1774474] New: Missing some coverage in certain variants
by bugzilla＠redhat.com 25 May '21

25 May '21

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/organizations… 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.

1 5

[Bug 1839471] New: OpenType variant of Lucida Typewriter has extra spacing around characters
by bugzilla＠redhat.com 25 May '21

25 May '21

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.

1 7

[Bug 1836987] New: Font descent miscalculated for some applications
by bugzilla＠redhat.com 25 May '21

25 May '21

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.

1 2

[Bug 1813230] New: [RFE] ghostscript add support for variable fonts from fontconfig
by bugzilla＠redhat.com 25 May '21

25 May '21

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.

1 2

[Bug 1813187] New: Cantarell-VF.otf fails on fontconfig's FcPatternGetInteger() call for FC_WEIGHT
by bugzilla＠redhat.com 25 May '21

25 May '21

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.

1 16

[Bug 1799156] New: apanov-edrip-fonts: FTBFS in Fedora rawhide/f32
by bugzilla＠redhat.com 25 May '21

25 May '21

https://bugzilla.redhat.com/show_bug.cgi?id=1799156 Bug ID: 1799156 Summary: apanov-edrip-fonts: FTBFS in Fedora rawhide/f32 Product: Fedora Version: rawhide Status: NEW Component: apanov-edrip-fonts Assignee: nicolas.mailhot(a)laposte.net Reporter: releng(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk Blocks: 1750908 (F32FTBFS) Target Milestone: --- Classification: Fedora apanov-edrip-fonts failed to build from source in Fedora rawhide/f32 https://koji.fedoraproject.org/koji/taskinfo?taskID=41315838 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild Please fix apanov-edrip-fonts at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, apanov-edrip-fonts will be orphaned. Before branching of Fedora 33, apanov-edrip-fonts will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1750908 [Bug 1750908] Fedora 32 FTBFS Tracker -- You are receiving this mail because: You are on the CC list for the bug.

1 15

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts-bugs May 2020