October 2015 - fonts-bugs - Fedora Mailing-Lists

[Bug 1228872] New: ttfcoverage from repo-font-audit crashes when checking Unicode 7.x fonts

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1228872 Bug ID: 1228872 Summary: ttfcoverage from repo-font-audit crashes when checking Unicode 7.x fonts Product: Fedora Version: 22 Component: fontpackages Severity: low Assignee: nicolas.mailhot(a)laposte.net Reporter: alex.ploumistos(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, tagoh(a)redhat.com External Bug ID: CPAN 85014 External Bug ID: CPAN 85014 ttfcoverage is probably not up to the Unicode 7.x specs, so when it comes across such fonts, it fails with a message like this one: Illegal division by zero at /usr/bin/ttfcoverage line 42. /usr/share/fontpackages/repo-font-audit.mk:56: recipe for target 'tmp/usr/share/fonts/gdouros-symbola/Symbola.ttf.rfo.unicover' failed make[1]: *** [tmp/usr/share/fonts/gdouros-symbola/Symbola.ttf.rfo.unicover] Error 255 make[1]: *** Waiting for unfinished jobs.... /usr/share/fontpackages/repo-font-audit.mk:36: recipe for target 'gdouros-symbola-fonts-0_7.21-0.3.20150430.fc21.noarch/' failed make: *** [gdouros-symbola-fonts-0_7.21-0.3.20150430.fc21.noarch/] Error 2 mv: cannot move ‘./gdouros-symbola-fonts-0_7.21-0.3.20150430.fc21.noarch/tmp/usr/share/fonts/gdouros-symbola/Symbola.ttf.rfo.fontlint’ to ‘../data/gdouros-symbola-fonts-0_7.21-0.3.20150430.fc21.noarch/usr_share_fonts_gdouros-symbola_Symbola.ttf.fontlint.txt’: No such file or directory Nothing is logged anywhere when this occurs. The only other reference to this I could find was on CPAN's bugtracker, but it's not that useful. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=H8Gnge9tF1&a=cc_unsubscribe

7 years, 9 months

1
1
0 / 0

[Bug 1228870] New: repo-font-audit doesn't know about xml metadata files

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1228870 Bug ID: 1228870 Summary: repo-font-audit doesn't know about xml metadata files Product: Fedora Version: 22 Component: fontpackages Severity: low Assignee: nicolas.mailhot(a)laposte.net Reporter: alex.ploumistos(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, tagoh(a)redhat.com When font packages that contain xml metadata files are checked with repo-font-audit, it throws the following error: fonts in packages that contain non-font data Since xml metadata files are now required for font packages, the script should be updated to recognize them. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=84GPn6G62c&a=cc_unsubscribe

7 years, 9 months

1
1
0 / 0

[Bug 1179691] New: Bold lower-case letter "s" looks in some cases too thin with Medium+ hinting

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1179691 Bug ID: 1179691 Summary: Bold lower-case letter "s" looks in some cases too thin with Medium+ hinting Product: Fedora Version: rawhide Component: liberation-fonts Severity: low Assignee: psatpute(a)redhat.com Reporter: michal.nowak(a)resist.ca 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 Created attachment 977206 --> https://bugzilla.redhat.com/attachment.cgi?id=977206&action=edit Lower-case "s" too thin on Full hinting Description of problem: Bold lower-case letter "s" in serif looks in some cases too thin with Medium and Full hinting, but look OK with hinting set to Slight or None. See attached screenshots from LO Writer from F21. See the "s" in a word "Midas" and "asked". It's 12 pt Liberation Serif, bold, paper is enlarged to 157 % of width of A4 paper. When the zoom ratio gets higher, the problem disappears, when zoomed out it's worse (but less visible). Version-Release number of selected component (if applicable): liberation-serif-fonts-1.07.4-4.fc21.noarch freetype-2.5.3-13.fc21.x86_64 libreoffice-core-4.3.5.2-4.fc21.x86_64 How reproducible: Always. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=IG83soyygr&a=cc_unsubscribe

7 years, 9 months

1
3
0 / 0

[Bug 1187678] New: RFC: Please give feedback about a compat stix-fonts 1.0.0

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1187678 Bug ID: 1187678 Summary: RFC: Please give feedback about a compat stix-fonts 1.0.0 Product: Fedora Version: rawhide Component: stix-fonts Assignee: nicolas.mailhot(a)laposte.net Reporter: paulo.cesar.pereira.de.andrade(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 I understand that to certain extent, this is kind of a revive of https://bugzilla.redhat.com/show_bug.cgi?id=885307 I made a tentative alternative, to handle https://fedorahosted.org/fpc/ticket/381 But the above is already quite old, but latest matplotlib still relies on its bundled stix-fonts-1.0.0 Instead of compat-stix-fonts it could be named something else including 1-0 or 1_0 in the name, in case stix-fonts is updated to the now available 2.0 version. This package at first would be used only by python-matplotlib and would remove the need of bundling the stix 1.0 fonts. Spec URL: https://pcpa.fedorapeople.org/compat-stix-fonts.spec SRPM URL: https://pcpa.fedorapeople.org/compat-stix-fonts-1.0.0-1.el7.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=PhtXAJgbtB&a=cc_unsubscribe

7 years, 9 months

1
1
0 / 0

[Bug 1084228] New: Hinting for Liberation Sans inferior at small font size

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1084228 Bug ID: 1084228 Summary: Hinting for Liberation Sans inferior at small font size Product: Fedora Version: 20 Component: liberation-fonts Assignee: psatpute(a)redhat.com Reporter: Eduard.Braun2(a)gmx.de 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 Created attachment 882473 --> https://bugzilla.redhat.com/attachment.cgi?id=882473&action=edit testcase with the problematic font charakteristics Wikipedia recently switched to a predefined CSS font stack for body font so even Windows users will be served with Liberation Sans if installed (e.g. because it is distributed with Libre Office). This made apparent inferior hinting of Liberation Sans with bold weight when rendered at the specific size of 0.875em (the font size used in MediaWiki's vector skin). Most notable "e"s have a very thick lower curve while the upper curve is much too thin. This also applies for variants like "è é ê ë". Funnily not for "œ æ" though which is rendered differently. Also notable is e.g. "s" which has thick upper/lower curves but is thin in the middle. A testcase with the described font characteristics set is attached. The screenshot shows the rendering in Firefox. The screenshot was created with Firefox 28.0 on Windows 7. The installed version of the Liberation fonts is 2.00.1 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=te4zKki7hK&a=cc_unsubscribe

7 years, 9 months

1
11
0 / 0

[Bug 1068918] New: Google Droid Sans font is displayed as [unknown] and [monotype], it breaks GTK+ apps view in KDE

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1068918 Bug ID: 1068918 Summary: Google Droid Sans font is displayed as [unknown] and [monotype], it breaks GTK+ apps view in KDE Product: Fedora Version: 20 Component: google-droid-fonts Assignee: nicolas.mailhot(a)laposte.net Reporter: carasin.berlogue(a)mail.ru QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, hobbes1069(a)gmail.com, nicolas.mailhot(a)laposte.net, paul(a)frixxon.co.uk, tremble(a)tremble.org.uk External Bug ID: Red Hat Bugzilla 963502 Description of problem: > [google-droid-sans-fonts] package is broken since F18. I want to select 'Droid Sans' font for KDE UI, but this font is displayed twice at [systemsettings]: with [unknown] and [monotype] suffixes. If I apply anyone of them, only KDE/Qt apps use 'Droid Sans' font, but GTK2/GTK3 apps use the defaul font (DejaVu Sans). Version-Release number of selected component (if applicable): > google-droid-sans-fonts-20120715-6.fc20.noarch How reproducible: > Always. Steps to Reproduce: > 1. [yum install google-droid-sans-fonts]; 2. start KDE session; 3. launch <select UI fonts> dialog at [systemsettings]; 4. 'Droid Sans' font is displayed twice: with [unknown] and [monotype] suffixes; 5. select and apply anyone — 'Droid Sans [unknown]' or 'Droid Sans [monotype]'; 6. KDE/Qt apps use the Droid Sans font, but GTK2/GTK3 apps use the defaul font (DejaVu Sans). Actual results: > 'Droid Sans' font is not applied for GTK2/GTK3 apps. This font is displayed twice at [systemsettings]: with [unknown] and [monotype] suffixes. Expected results: > 'Droid Sans' font is applied for all the apps. This font is displayed once at [systemsettings] — without any suffix. Additional info: > This bug is several years old. https://bugzilla.redhat.com/show_bug.cgi?id=963502#c1 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EIzrPE5DPR&a=cc_unsubscribe

7 years, 9 months

1
4
0 / 0

[Bug 1273554] New: Too high mono font; please, upgrade to the latest upstream

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1273554 Bug ID: 1273554 Summary: Too high mono font; please, upgrade to the latest upstream Product: Fedora Version: rawhide Component: mozilla-fira-fonts Assignee: relrod(a)redhat.com Reporter: mcepl(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: admiller(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, relrod(a)redhat.com Created attachment 1084829 --> https://bugzilla.redhat.com/attachment.cgi?id=1084829&action=edit Screenshot of the situation Description of problem: The current version of the Mozilla Fira Mono is too high, so it makes it hard to use it. When using the font from the upstream the situation is a way better. Version-Release number of selected component (if applicable): mozilla-fira-fonts-3.111-3 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0Spm3ewX8y&a=cc_unsubscribe

7 years, 10 months

1
21
0 / 0

[Bug 1169979] New: Some fonts not in fontconfig cache on Fedora 21 live images

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1169979 Bug ID: 1169979 Summary: Some fonts not in fontconfig cache on Fedora 21 live images Product: Fedora Version: 21 Component: fontconfig Assignee: tagoh(a)redhat.com Reporter: awilliam(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, pnemade(a)redhat.com, tagoh(a)redhat.com We've spotted an issue with Fedora 21 live images where some installed fonts appear to be missing from the fontconfig cache in the live environment. An 'fc-cache -f' fixes this. For instance, on the Fedora 21 Final RC2 Workstation x86_64 live: [root@localhost liveuser]# fc-list | wc -l 141 [root@localhost liveuser]# fc-cache --force [root@localhost liveuser]# fc-list | wc -l 159 The specific fonts that are missing on that image are: /usr/share/fonts/dejavu/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /usr/share/fonts/dejavu/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold /usr/share/fonts/dejavu/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique /usr/share/fonts/dejavu/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book /usr/share/fonts/dejavu/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold Italic /usr/share/fonts/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold /usr/share/fonts/dejavu/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic /usr/share/fonts/dejavu/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed,Book /usr/share/fonts/dejavu/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic /usr/share/fonts/dejavu/DejaVuSerif.ttf: DejaVu Serif:style=Book /usr/share/fonts/google-noto/NotoSansTagalog-Regular.ttf: Noto Sans Tagalog:style=Regular /usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai Viet:style=Regular /usr/share/fonts/liberation/LiberationSerif-BoldItalic.ttf: Liberation Serif:style=Bold Italic /usr/share/fonts/liberation/LiberationSerif-Bold.ttf: Liberation Serif:style=Bold /usr/share/fonts/liberation/LiberationSerif-Italic.ttf: Liberation Serif:style=Italic /usr/share/fonts/liberation/LiberationSerif-Regular.ttf: Liberation Serif:style=Regular The log of the compose is here: https://kojipkgs.fedoraproject.org//work/tasks/5463/8275463/root.log In comparison, the i686 Workstation live is 'missing' only /usr/share/fonts/google-noto/NotoSansTaiViet-Regular.ttf: Noto Sans Tai Viet:style=Regular its compose log is here: https://kojipkgs.fedoraproject.org//work/tasks/5460/8275460/root.log to me, it appears the affected cases are ones where more than one package contains fonts in the same directory, for packages installed *after* the fontconfig package. The fontconfig package has an 'fc-cache -f' in its %post, so any inconsistencies that exist before it's installed get fixed by that. My first thesis was 'for any given directory, only fonts from the first package installed after fontconfig will make it to the cache, fonts in the same directory from subsequently-installed packages won't be added'. But it doesn't seem to be that simple, because some fonts in /usr/share/fonts/google-noto *are* added - the first 'noto' package installed is google-noto-sans-lisu-fonts , and after that several more noto packages are installed. The fonts from google-noto-sans-mandaic-fonts, google-noto-sans-meeteimayek-fonts , and google-noto-sans-tai-tham-fonts *do* get added to the cache - but the fonts from google-noto-sans-tagalog-fonts and google-noto-sans-tai-viet-fonts do *not* get added. It's quite odd. This is a fairly bad bug because of its impact on DejaVu Sans Mono: this is the default monospace font for both Workstation and KDE (and I think the non-blocking spins too). Its absence from the cache results in them using Nimbus Mono L as their monospace fonts, which is a pretty crappy font, ugly and hard to read. The workaround is easy once you know it, but if you don't, you just think we have a really bad font. There's an easy big hammer workaround we can use for a quick rebuild of the RC2 lives, if we like: --- a/fedora-live-base.ks +++ b/fedora-live-base.ks @@ -299,6 +299,12 @@ rm -f /core* # convince readahead not to collect # FIXME: for systemd +# forcibly regenerate fontconfig cache (so long as this live image has +# fontconfig) - see #XXXXXXX +if [ -x /usr/bin/fc-cache ] ; then + fc-cache -f +fi + %end i.e., just do an fc-cache -f at the end of live generation %post. I've tested that locally, and it works, the generated Workstation image has 159 fonts in fc-list (I also generated an image with the exact same config and build host, but no change to spin-kickstarts, to verify that it reproduced the bug, and it does). The real fix should likely be in fc-cache, but the spin-kickstarts workaround would solve this problem for F21. I think fc-cache's behaviour must have changed between F20 and F21, as F20 doesn't appear to be affected by this at all, at least not the x86_64 desktop live. All F21 images I've tested seem to be affected to some extent, though the exact affected fonts vary depending on the package install order that yum decided on. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YTmueYxE1e&a=cc_unsubscribe

7 years, 10 months

1
26
0 / 0

[Bug 527740] New: [ml_IN] Applying Backspace to a chillu conjunct followed by punctuation/SPACE results in deletion of the chillu also

by Red Hat Bugzilla

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [ml_IN] Applying Backspace to a chillu conjunct followed by punctuation/SPACE results in deletion of the chillu also https://bugzilla.redhat.com/show_bug.cgi?id=527740 Summary: [ml_IN] Applying Backspace to a chillu conjunct followed by punctuation/SPACE results in deletion of the chillu also Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Keywords: i18n Severity: medium Priority: low Component: pango AssignedTo: besfahbo(a)redhat.com ReportedBy: apeter(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: eng-i18n-bugs(a)redhat.com, besfahbo(a)redhat.com, fedora-fonts-bugs-list(a)redhat.com, smc-discuss(a)googlegroups.com Classification: Fedora Target Release: --- Created an attachment (id=363982) --> (https://bugzilla.redhat.com/attachment.cgi?id=363982) Screenshot for chillu conjuncts Description of problem: When chillu conjuncts are followed by any punctuation marks like "!", ".", ",", "'", "?" or SPACE, ie when a word ends with a chillu conjunct, and followed by a punctuation mark or a SPACE, using Backspace to delete the punctuation mark or SPACE results in the deletion of chillu conjunct together with the punctuation mark/SPACE. Version-Release number of selected component (if applicable): pango 1.26.0-1.fc12 i686 How reproducible: Always Steps to Reproduce: 1. Open gedit 2. type any of chillu conjunct, eg: 0D28, 0D4D, 200D OR type a word ending with chillu conjunct, eg: 0D05, 0D35, 0D28, 0D4D, 200D 3. type any punctuation marks like "!", ".", ",", "'", "?" or SPACE 4. Press Backspace Actual results: When using Backspace after chillu conjunct followed by punctuation mark or SPACE, instead of deleting punctuation mark or SPACE only, the chillu conjunct also gets deleted. Expected results: When using Backspace after chillu conjunct followed by punctuation mark or SPACE, only the punctuation mark/SPACE should get deleted. Additional info: 1. This does not happen when chillu comes in between a word. eg: നന്‍മ (0D28, 0D28, 0D4D, 200D, 0D2E) 2. This issue is not present in oowriter and kwrite. When above steps are reproduced, deletions happens in correct order. Versions used: libicu-4.2.1-6.fc12 i686 qt-4.5.2-22.fc12 i686 3. Screenshot attached for chillu conjuncts and eg of words with chillu -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

7 years, 11 months

1
19
0 / 0

[Bug 1269404] New: Update with latest upstream release with split tarballs

by Red Hat Bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1269404 Bug ID: 1269404 Summary: Update with latest upstream release with split tarballs Product: Fedora Version: 23 Component: google-noto-fonts Assignee: psatpute(a)redhat.com Reporter: psatpute(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: fonts-bugs(a)lists.fedoraproject.org, i18n-bugs(a)lists.fedoraproject.org, psatpute(a)redhat.com, pwu(a)redhat.com Ref: https://github.com/fedora-infra/fedora-packages/issues/161 Dear Fedora maintainers, currently, this page: https://apps.fedoraproject.org/packages/google-noto-fonts/overview/ lists the following as project homepage: https://code.google.com/p/noto However, we recently moved from Google Code to GitHub; to cope with size limitations, we split the fonts over multiple repositories. The new locations are here: https://github.com/googlei18n/noto-fonts https://github.com/googlei18n/noto-cjk https://github.com/googlei18n/noto-emoji -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Iwmnhx7uNF&a=cc_unsubscribe

7 years, 11 months

1
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts-bugs October 2015