fonts-bugs January 2023

fonts-bugs@lists.fedoraproject.org

1 participants
37 discussions

[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

[Bug 1999864] New: Cannot find package with font for Coptic although such a package exists for Fedora 34
by bugzilla＠redhat.com 19 Sep '24

19 Sep '24

https://bugzilla.redhat.com/show_bug.cgi?id=1999864 Bug ID: 1999864 Summary: Cannot find package with font for Coptic although such a package exists for Fedora 34 Product: Fedora Version: 34 Status: NEW Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: mfabian(a)redhat.com 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, i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com, pnemade(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 1819530 --> https://bugzilla.redhat.com/attachment.cgi?id=1819530&action=edit Gnome Software unable to find Coptic fonts Using Fedora-Workstation-Live-x86_64-34-1.2.iso in qemu. I played with emoji picker and Gnome popped up something requesting more fonts. I clicked and then Gnome Software said: “Unable to find the Coptic, Persian, Old (ca. 600-400 B.C.), Ugaritic you were searching for. Please see _the documentation_ for more information.” See attached screenshot. -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 2088665] New: Noto Sans is chosen to display symbol characters it doesn't contain
by bugzilla＠redhat.com 18 Mar '24

18 Mar '24

https://bugzilla.redhat.com/show_bug.cgi?id=2088665 Bug ID: 2088665 Summary: Noto Sans is chosen to display symbol characters it doesn't contain Product: Fedora Version: 36 Status: NEW Component: google-noto-fonts Assignee: tagoh(a)redhat.com Reporter: talk(a)danielflaum.net 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 Created attachment 1881507 --> https://bugzilla.redhat.com/attachment.cgi?id=1881507&action=edit A zipped sample PDF and image of relevant portion of PDF when affected by the issue Description of problem: Given a PDF lacking embedded fonts which use certain characters (including → and ≥), GNOME's Evince on Fedora 36 chooses to substitute the Noto Sans font, which does not include these characters. Version-Release number of selected component (if applicable): How reproducible: Successfully reproduced by two people independently. Steps to Reproduce: 1. Boot a fresh copy of Fedora 36 (the Live version in a VM will do). 2. Open the attached sample PDF in GNOME Evince (aka Document Viewer). 3. Observe the missing characters in the second paragraph from the top of the page. Actual results: See attached image. Expected results: The missing characters should be displayed properly as → (that is, https://unicode-table.com/en/2192/) Additional info: The filer initially sought help at https://ask.fedoraproject.org/t/missing-characters-in-pdfs-since-upgrade-fr…, which may be informative in reproducing the issue. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2088665

1 26

[Bug 2093080] New: Default fonts for Arabic do not match the font packages list
by bugzilla＠redhat.com 15 Mar '24

15 Mar '24

https://bugzilla.redhat.com/show_bug.cgi?id=2093080 Bug ID: 2093080 Summary: Default fonts for Arabic do not match the font packages list Product: Fedora Version: 36 Hardware: All OS: Linux Status: NEW Component: fontconfig Severity: medium Assignee: tagoh(a)redhat.com Reporter: awilliam(a)redhat.com 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, i18n-bugs(a)lists.fedoraproject.org, mclasen(a)redhat.com, pnemade(a)redhat.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, tagoh(a)redhat.com Target Milestone: --- Classification: Fedora There's a test case: https://fedoraproject.org/wiki/QA:Testcase_i18n_default_fonts which requires checking the default fonts for various languages against a list, http://tagoh.fedorapeople.org/fonts/fc-test.sh . The current default fonts for Arabic installs do not match the list. The list states sans should be DejaVu Sans, serif should be FreeSerif or MPH 2B Damase, and mono should be DejaVu Sans Mono. These may have been changed recently, as our openQA reference text file expects them to be Noto Naskh Arabic (for both sans and serif?) and PakType Naskh Basic for mono. In any case, what we actually see doesn't match either the list or the openQA reference file. We see "Noto Sans Arabic" and "PakType Naqsh" in the output from the test, I think for serif (yes really) and monospace respectively. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2093080

1 20

[Bug 1761885] New: rpm -V complains about mode for ghost .uuid files
by bugzilla＠redhat.com 24 Feb '24

24 Feb '24

https://bugzilla.redhat.com/show_bug.cgi?id=1761885 Bug ID: 1761885 Summary: rpm -V complains about mode for ghost .uuid files Product: Fedora Version: rawhide Status: NEW Component: fontpackages Assignee: nicolas.mailhot(a)laposte.net Reporter: mtasaka(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, redhat-bugzilla(a)linuxnetz.de, tagoh(a)redhat.com Target Milestone: --- Link ID: Red Hat Bugzilla 1564432 Classification: Fedora Description of problem: rpm -Va complains a lot about mode of %ghost .uuid files: .M....... g /usr/share/fonts/paktype-naqsh/.uuid .M....... g /usr/share/fonts/lilypond/.uuid .M....... g /usr/share/fonts/sil-padauk/.uuid .M....... g /usr/share/fonts/google-droid/.uuid .M....... g /usr/share/fonts/lilypond/.uuid .M....... g /usr/share/fonts/smc-suruma/.uuid .M....... g /usr/share/fonts/google-android-emoji/.uuid .M....... g /usr/share/fonts/google-crosextra-carlito/.uuid .M....... g /usr/share/fonts/lohit-assamese/.uuid .M....... g /usr/share/fonts/dejavu/.uuid .M....... g /usr/share/fonts/lohit-telugu/.uuid .M....... g /usr/share/fonts/lilypond/.uuid ..... Looks like fontpackages-devel template rpmmacro creates .uuid which %ghost %atttr(0000) e.g. [root@localhost ~]# rpm -qf /usr/share/fonts/google-droid/.uuid google-droid-sans-fonts-20120715-16.fc31.noarch [root@localhost ~]# rpm -qlv google-droid-sans-fonts | grep uuid ---------- 1 root root 0 7月 25 23:03 /usr/share/fonts/google-droid/.uuid ref: https://src.fedoraproject.org/rpms/fontpackages/blob/master/f/fontpackages-… but I guess %transfiletriggerin script by fontconfig creates .uuid as 0755 permission (perhaps) Version-Release number of selected component (if applicable): fontpackages-filesystem-1.44-25.fc31.noarch fontconfig-2.13.92-3.fc31.x86_64 fontconfig-2.13.92-3.fc31.i686 google-droid-sans-fonts-20120715-16.fc31.noarch How reproducible: 100% Steps to Reproduce: 1. See above, try $ rpm -Va 2. 3. Actual results: See above, lots of .uuid permission complaint Expected results: No complaint by rpm -Va Additional info: -- You are receiving this mail because: You are on the CC list for the bug.

1 20

[Bug 2112732] New: Fail to build from source
by bugzilla＠redhat.com 18 Feb '24

18 Feb '24

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 4

[Bug 2096153] New: strange font priorities in Firefox
by bugzilla＠redhat.com 05 Dec '23

05 Dec '23

https://bugzilla.redhat.com/show_bug.cgi?id=2096153 Bug ID: 2096153 Summary: strange font priorities in Firefox Product: Fedora Version: rawhide Hardware: x86_64 OS: Linux Status: NEW Component: google-droid-fonts Assignee: ali.erdinc.koroglu(a)intel.com Reporter: tagoh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: ali.erdinc.koroglu(a)intel.com, contact(a)dannycolin.com, fonts-bugs(a)lists.fedoraproject.org, nicolas.mailhot(a)laposte.net, oliver(a)redhat.com, skyfaller(a)gmail.com Depends On: 2062386 Target Milestone: --- Classification: Fedora Cloning to focus on the Droid specific issue here. please ignore URW related description. +++ This bug was initially created as a clone of Bug #2062386 +++ Description of problem: Sometimes, when using a native font stack in CSS on a web page, fonts that are not in the font stack at all are substituted for the desired fonts. This only seems to affect web pages viewed using: - Fedora (not Ubuntu, Debian 11, or Manjaro) - Firefox (not Chrome or Chromium) - When using the RPM version or Mozilla's official build from their website (not the Flatpak) Happens in the stable version of Firefox, Firefox Beta, and Firefox nightly. Two substitutions I've identified so far: - Droid Sans is substituted for Open Sans - P052 is substituted for 'URW Palladio L' or Palatino Substituting for Palatino may be less objectionable, since that's a generic choice, but URW Palladio L is rather specific and it's surprising to see the substitution. This also wouldn't be as objectionable if the font substitutions were better. Droid Sans doesn't look much like Open Sans at all, and P052 looks really ugly (it has unevenly sized letters). In Firefox Flatpak, it instead substitutes the better-looking 'TeX Gyre Pagella', and only does that for Palatino, not for 'URW Palladio L' (which was higher priority in my font stack). This is more desirable behavior. The source of the problem seems to be that if you run the following command: fc-match :family="Open Sans" It returns Droid Sans. Possibly related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1820166 https://bugzilla.mozilla.org/show_bug.cgi?id=1406790 How reproducible: Consistently Steps to Reproduce: 1. Open a clean Fedora 35 install, and verify that Open Sans is not installed. 2. Create the following web page and view it in a browser: ``` <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title></title> <style> h1,h2,h3,h4 { font-family: Open Sans, Fira Sans; } </style> </head> <body> <h1>Hello World</h1> <p>Lorem ipsum dolor sit amet.</p> </body> </html> ``` Alternately, view a real live (but more complex) website at https://www.maximumethics.dev/ Actual results: Notice that the text on the webpage is displayed in Droid Sans, not Open Sans. Expected results: The webpage displays the next available font in the font stack, Fira Sans in this case, or the browser's default font if you don't have Fira Sans. --- Additional comment from Akira TAGOH on 2022-03-30 09:26:08 UTC --- Well, maybe good to file a separate bug to object each substitutions. For Open Sans, google-droid-sans-fonts has the following config: <alias binding="same"> <family>Open Sans</family> <accept> <family>Droid Sans</family> </accept> </alias> This is the reason why you see that behavior. For URW Palladio L, urw-base35-fonts-common has the following config: <alias binding="same"> <family>URW Palladio L</family> <accept> <family>P052</family> </accept> </alias> And finally for Palatino, it is in urw-base35-p052-fonts: <alias binding="same"> <family>Palatino</family> <accept> <family>P052</family> </accept> </alias> Although those urw config are coming from upstream. so if you have any objections for them, it would be good to talk with URW upstream. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2062386 [Bug 2062386] strange font priorities in Firefox -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2096153

1 6

[Bug 2151945] New: libfontenc-1.1.7 is available
by bugzilla＠redhat.com 06 Oct '23

06 Oct '23

https://bugzilla.redhat.com/show_bug.cgi?id=2151945 Bug ID: 2151945 Summary: libfontenc-1.1.7 is available Product: Fedora Version: rawhide Status: NEW Component: libfontenc Keywords: FutureFeature, Triaged Assignee: btissoir(a)redhat.com Reporter: upstream-release-monitoring(a)fedoraproject.org QA Contact: extras-qa(a)fedoraproject.org CC: ajax(a)redhat.com, btissoir(a)redhat.com, caolanm(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 1.1.7 Upstream release that is considered latest: 1.1.7 Current version/release in rawhide: 1.1.6-1.fc38 URL: https://gitlab.freedesktop.org/xorg/lib/libfontenc 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/1613/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/libfontenc -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2151945

1 3

[Bug 2087984] New: Version of Source Code Pro currently packaged breaks in some cases
by bugzilla＠redhat.com 30 Aug '23

30 Aug '23

https://bugzilla.redhat.com/show_bug.cgi?id=2087984 Bug ID: 2087984 Summary: Version of Source Code Pro currently packaged breaks in some cases Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: adobe-source-code-pro-fonts Severity: medium Assignee: mattrose(a)folkwolf.net Reporter: jharmiso(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, mark(a)net-c.com, mattrose(a)folkwolf.net Target Milestone: --- Classification: Fedora Created attachment 1880946 --> https://bugzilla.redhat.com/attachment.cgi?id=1880946&action=edit A screenshot of dmesg in Alacritty with Source Code Pro selected Description of problem: Source Code Pro version 2.030, currently packaged for all versions of Fedora and in EPEL, includes an SVG table that causes the freetype library to be unable to calculate cell height, resulting in unusable output with lines stacked on top of each other. Version-Release number of selected component (if applicable): 2.030.1.050-<any> How reproducible: Always Steps to Reproduce: 1. Install adobe-source-code-pro-fonts and alacritty (a terminal emulator that uses freetype through the crossfont crate) from the current release versions. 2. Configure alacritty to use Source Code Pro. Example config: ~/.config/alacritty/alacritty.yml: ```yaml font: normal: family: Source Code Pro style: Regular bold: family: Source Code Pro style: Bold italic: family: Source Code Pro style: Italic bolt_italic: family: Source Code Pro style: Bold Italic size: 10 ``` 3. Launch alacritty and attempt to use the terminal Actual results: The terminal is completely unusable with 1px line height, although the font is rendering at the correct size. Expected results: The terminal has a normal font display behavior and is usable. Additional info: 2.038 is available and appears to fix the issue (https://github.com/adobe-fonts/source-code-pro/releases) See some additional discussion here: https://github.com/alacritty/alacritty/issues/6048 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2087984

1 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts-bugs January 2023