fonts-bugs June 2024

fonts-bugs@lists.fedoraproject.org

1 participants
35 discussions

[Bug 2267629] New: liberation-mono-fonts breaks default font for Hebrew
by bugzilla＠redhat.com 11 Jul '25

11 Jul '25

https://bugzilla.redhat.com/show_bug.cgi?id=2267629 Bug ID: 2267629 Summary: liberation-mono-fonts breaks default font for Hebrew Product: Fedora Version: 40 OS: Linux Status: NEW Component: google-noto-fonts Keywords: i18n Severity: medium Assignee: tagoh(a)redhat.com Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora google-noto-sans-hebrew-vf-fonts is supposed to be a default monospace font for Hebrew though, liberation-mono-fonts is picked up as the default monospace font when it is installed. This happens because liberation use 59 as the priority number although google-noto-sans-hebrew-vf-fonts use 66. The priority number needs to be updated. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2267629 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 4

[Bug 2166360] New: sil-andika-fonts-6.200 is available
by bugzilla＠redhat.com 10 Jul '25

10 Jul '25

https://bugzilla.redhat.com/show_bug.cgi?id=2166360 Bug ID: 2166360 Summary: sil-andika-fonts-6.200 is available Product: Fedora Version: rawhide Status: NEW Component: sil-andika-fonts Keywords: FutureFeature, Triaged Assignee: aekoroglu(a)linux.intel.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: aekoroglu(a)linux.intel.com, fonts-bugs(a)lists.fedoraproject.org, nicolas.mailhot(a)laposte.net Target Milestone: --- Classification: Fedora Releases retrieved: 6.200 Upstream release that is considered latest: 6.200 Current version/release in rawhide: 6.101-3.fc38 URL: https://software.sil.org/andika/ 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://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_M… 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/4816/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/sil-andika-fonts -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2166360

1 8

[Bug 2112732] New: Fail to build from source
by bugzilla＠redhat.com 16 May '25

16 May '25

https://bugzilla.redhat.com/show_bug.cgi?id=2112732 Bug ID: 2112732 Summary: Fail to build from source Product: Fedora Version: rawhide Status: NEW Component: campivisivi-titillium-fonts Assignee: luya_tfz(a)thefinalzone.net Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, luya_tfz(a)thefinalzone.net Target Milestone: --- Classification: Fedora Description of problem: Titillium_roman_upright_italic_2_0_OT.zip contains two directory. one is Titillium_roman_upright_italic_2_0_OT which is specified as a base directory in the spec file. another one is __MACOSX. the spec file doesn't clean up __MACOSX, thus, the build stop on extracting like: + /usr/lib/rpm/rpmuncompress -x /var/home/tagoh/rpmbuild/SOURCES/Titillium_roman_upright_italic_2_0_OT.zip replace __MACOSX/Titillium_roman_upright_italic_2_0_OT/._Titillium-Black.otf? [y]es, [n]o, [A]ll, [N]one, [r]ename: Version-Release number of selected component (if applicable): campivisivi-titillium-fonts-20120913-25.fc37 How reproducible: always Steps to Reproduce: 1.download SRPM 2.rpmbuild --rebuild campivisivi-titillium-fonts-20120913-25.fc37.src.rpm 3.try again once the rebuild finished. Actual results: the rebuild always fails except first try. Expected results: the rebuild should be successfully finished any time. Additional info: -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2112732

1 6

[Bug 1954359] Many emoji don't show up in Qt apps because qt does not handle 'emoji' font family
by bugzilla＠redhat.com 07 May '25

07 May '25

https://bugzilla.redhat.com/show_bug.cgi?id=1954359 --- Comment #18 from Peng Wu <pwu(a)redhat.com> --- Okay, I will submit the change to Qt upstream for review. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1954359 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

2 1

[Bug 2277345] New: NotoSansMono[wght].ttf file name causes scripts with failglob enabled to fail
by bugzilla＠redhat.com 03 Mar '25

03 Mar '25

https://bugzilla.redhat.com/show_bug.cgi?id=2277345 Bug ID: 2277345 Summary: NotoSansMono[wght].ttf file name causes scripts with failglob enabled to fail Product: Fedora Version: 40 Hardware: All OS: Linux Status: NEW Component: google-noto-fonts Severity: medium Assignee: tagoh(a)redhat.com Reporter: hartsjc(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora shopt failglob If set, patterns which fail to match filenames during pathname expansion result in an expansion error. Using this feature is good practice in scripts as helps prevent scripting mistakes; however, having file name with square brackets causes failures. And with Fedora 40 upgrade seems google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch has added one with: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf Reproducible: Always Steps to Reproduce: 1. Causes globs that don't expand to cause errors $ shopt -s failglob 2. Try use files from rpm as variable, and fail $ for file in $(rpm -q --list google-noto-sans-mono-vf-fonts) ; do [[ -f "/${file}" ]] || echo "${file}" done -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf 3. Note the RC $ echo $? 1 4. Or even command line $ rpm -qf /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf $ rpm -qf '/usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf' google-noto-sans-mono-vf-fonts-20240301-2.fc40.noarch Actual Results: -bash: no match: /usr/share/fonts/google-noto-vf/NotoSansMono[wght].ttf Expected Results: no error accessing files with failglob shopt enabled started fedora 40 upgrade, as daily script of mine fails because this file is included in initramfs too. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2277345 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 6

[Bug 2274629] New: Please branch and build artwiz-aleczapka-fonts in epel9
by bugzilla＠redhat.com 26 Feb '25

26 Feb '25

https://bugzilla.redhat.com/show_bug.cgi?id=2274629 Bug ID: 2274629 Summary: Please branch and build artwiz-aleczapka-fonts in epel9 Product: Fedora EPEL Version: epel9 Status: NEW Component: artwiz-aleczapka-fonts Assignee: dchen(a)redhat.com Reporter: davide(a)cavalca.name QA Contact: extras-qa(a)fedoraproject.org CC: dchen(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, spotrh(a)gmail.com Blocks: 1914423 (EPELPackagersSIG) Target Milestone: --- Classification: Fedora Please branch and build artwiz-aleczapka-fonts in epel9. If you do not wish to maintain artwiz-aleczapka-fonts in epel9, or do not think you will be able to do this in a timely manner, the EPEL Packagers SIG would be happy to be a co-maintainer of the package; please add the epel-packagers-sig group through https://src.fedoraproject.org/rpms/artwiz-aleczapka-fonts/addgroup and grant it commit access, or collaborator access on epel* branches. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1914423 [Bug 1914423] Tracker for epel-packagers-sig -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2274629 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 10

[Bug 2281473] New: Bundle all Adobe Source fonts into a single package like ibm-plex-fonts-all
by bugzilla＠redhat.com 25 Jan '25

25 Jan '25

https://bugzilla.redhat.com/show_bug.cgi?id=2281473 Bug ID: 2281473 Summary: Bundle all Adobe Source fonts into a single package like ibm-plex-fonts-all Product: Fedora Version: 40 Hardware: x86_64 OS: Linux Status: NEW Component: adobe-source-sans-pro-fonts Keywords: Desktop, FutureFeature Severity: low Assignee: pikachu.2014(a)gmail.com Reporter: sbnavi20(a)proton.me QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, mavit(a)mavit.org.uk, pikachu.2014(a)gmail.com Target Milestone: --- Classification: Fedora Adobe Source is personally my font of choice for interfaces and I'm glad it is available on Fedora repositories. Right now, the Adobe Source font family is fragmented in several packages. adobe-source-code-pro-fonts adobe-source-sans-pro-fonts adobe-source-serif-pro-fonts adobe-source-han-mono-fonts adobe-source-han-sans-cn-fonts adobe-source-han-sans-twhk-fonts adobe-source-han-sans-jp-fonts adobe-source-han-code-jp-fonts adobe-source-han-sans-kr-fonts adobe-source-han-sans-tw-fonts adobe-source-han-serif-cn-fonts adobe-source-han-serif-jp-fonts adobe-source-han-serif-kr-fonts adobe-source-han-serif-tw-fonts I suggest gathering all font packages generated from adobe-source-fonts in a single package like it is done with ibm-plex-fonts-all. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2281473 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 1

[Bug 2262410] New: Fonts are looking wrong after 20240101 update
by bugzilla＠redhat.com 27 Nov '24

27 Nov '24

https://bugzilla.redhat.com/show_bug.cgi?id=2262410 Bug ID: 2262410 Summary: Fonts are looking wrong after 20240101 update Product: Fedora Version: 39 Hardware: x86_64 OS: Linux Status: NEW Component: google-noto-fonts Severity: medium Assignee: tagoh(a)redhat.com Reporter: priv.luk(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, petersen(a)redhat.com, pwu(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora Fonts look improperly in multiple places, e.g. mpv or KDE file picker. Reproducible: Always Steps to Reproduce: 1. Open mpv and look at OSD fonts Actual Results: Fonts look wrong Expected Results: Fonts look properly See https://github.com/mpv-player/mpv/issues/13396 for screenshots. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2262410 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-sp…

1 37

[Bug 1999078] New: Hinting broken for Bitstream Vera/DejaVu in Epiphany
by bugzilla＠redhat.com 27 Nov '24

27 Nov '24

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.

1 43

[Bug 1833858] New: Hangul Jamo is seperated and printed respectively
by bugzilla＠redhat.com 27 Nov '24

27 Nov '24

https://bugzilla.redhat.com/show_bug.cgi?id=1833858 Bug ID: 1833858 Summary: Hangul Jamo is seperated and printed respectively Product: Fedora Version: 32 Status: NEW Component: google-droid-fonts Assignee: nicolas.mailhot(a)laposte.net Reporter: hyunwoo.park(a)gmail.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 Created attachment 1687129 --> https://bugzilla.redhat.com/attachment.cgi?id=1687129&action=edit wrong display of Hangul at LibreOffice Writer Description of problem: When Hangul is output to the monitor, Chosung, Neutral, and Jongseong are output separately. Version-Release number of selected component (if applicable): Font file, /usr/share/fonts/google-droid-sans-fonts/DroidSansFallbackFull.ttf, of google-droid-sans-fonts-20200215-3.fc32.noarch How reproducible: If you create a test.html containing "가속도" and open the file in the chrome browser, the Korean alphabet will be displayed separately. Or, write "가속도" at LibreOffice Writer and select font as "Droid Sans Fallback". Steps to Reproduce: 1. write "가속도" at LibreOffece Writer 2. select the text and change font name to "Droid Sans Fallback" Actual results: The text is displayed like "가ㅅㅗㄱㄷㅗ". Expected results: Text should be "가속도" Additional info: https://kldp.org/node/163247 -- You are receiving this mail because: You are on the CC list for the bug.

1 43

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts-bugs June 2024