May 2022 - fonts-bugs - Fedora Mailing-Lists

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #7 from Akira TAGOH <tagoh(a)redhat.com> --- Sorry, "variable fonts and hinting" thing was false alarm. actually it depends. "fonthashint" property is supposed to be added by fontconfig automatically. If you don't like it, you can modify it. and "fonthashint" is set to false, autohinting will be used for them. this logic is supposed to be done by 09-autohint-if-no-hinting.conf though, this one isn't however enabled by default. I totally missed that. So it wouldn't affect so much so far. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #6 from Hedayat Vatankhah <hedayatv(a)gmail.com> --- Thanks a lot, so I"ll create separate sub-packages for variable fonts. However, you said that variable fonts should have "fonthashint" property set to false. But, for Noto Arabic fonts, it is the other way around: VF fonts have set fonthashint property set to true while Non-VF fonts have set it to false. This is from 56-google-noto-sans-arabic-vf.conf: <edit name="fonthashint" mode="append"> <bool>true</bool> </edit> Which one is correct? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 Akira TAGOH <tagoh(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tagoh(a)redhat.com --- Comment #5 from Akira TAGOH <tagoh(a)redhat.com> --- (In reply to Hedayat Vatankhah from comment #4) > Yes, sure. And thank you for reviewing my package :) > > Just a quick question (part of the above emails): should I package variable > version of the fonts separately from the normal ones? I've seen that at > least some fonts, e.g. the Noto fonts, have separate package for variable > fonts (-vf subpackages), but I don't know if I should do the same (by > definition, seems that all of them belong to a single family). If I > can/should put them in a separate subpackage, what should their fontconfig > file contain? For Noto (Arabic) fonts, I saw the variable fonts have 'have > hints' (not the exact word) set to true while non-variable version has set > it to false. I wonder if the same thing is correct for all variable fonts or > it is just specific to Noto fonts? > > Thanks again, I'll upload a new version in a few hours. You should have a variable font in a separate package because both, variable and non-variable fonts eventually looks same at the application level as they have same family name and both is available at a sort of the font picker which isn't better experience. Also, the users aren't able to recognize which one is a variable or non-variable. This is the reason why we have a separate package for variable and non-variable fonts. For "fonthashint" property in fontconfig, variable fonts doesn't have hinting. fontconfig has a recipe to enable "autohint"ing if "fonthashint" is set to false. this is to provide better rendering with variable fonts. Hope that helps. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #4 from Hedayat Vatankhah <hedayatv(a)gmail.com> --- Yes, sure. And thank you for reviewing my package :) Just a quick question (part of the above emails): should I package variable version of the fonts separately from the normal ones? I've seen that at least some fonts, e.g. the Noto fonts, have separate package for variable fonts (-vf subpackages), but I don't know if I should do the same (by definition, seems that all of them belong to a single family). If I can/should put them in a separate subpackage, what should their fontconfig file contain? For Noto (Arabic) fonts, I saw the variable fonts have 'have hints' (not the exact word) set to true while non-variable version has set it to false. I wonder if the same thing is correct for all variable fonts or it is just specific to Noto fonts? Thanks again, I'll upload a new version in a few hours. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #3 from Parag AN(पराग) <panemade(a)gmail.com> --- Just to note one more thing after quicklook, Family names should be written as they are in font files. You have added hyphen in place of space character. e.g. %global fontfamily7 Vazirmatn-RD-UI-NL should be written as %global fontfamily7 Vazirmatn RD UI NL Just check the metadata of font Vazirmatn-UI-FD-NL-Regular.ttf which shows Family: Vazirmatn UI FD NL So correct the same for all other sub-packages. Remove all comments to make SPEC file more readable. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #2 from Parag AN(पराग) <panemade(a)gmail.com> --- I wanted to review but not getting time. The more complex/subpackages in SPEC, more it will take time to review. Can you first try to remove comments from SPEC file and submit again same package? -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 2081539] Review Request: vazirmatn-fonts - A simple and legible Persian/Arabic typeface

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=2081539 --- Comment #1 from Hedayat Vatankhah <hedayatv(a)gmail.com> --- Two emails which are related to packaging of this font: https://lists.fedoraproject.org/archives/list/fonts@lists.fedoraproject.o... https://lists.fedoraproject.org/archives/list/fonts@lists.fedoraproject.o... -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2081539

1 year, 11 months

1
0
0 / 0

[Bug 1926533] New: Postinstall scripts are failable, fail during KDE netinst (due to dependency loop most likely)

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1926533 Bug ID: 1926533 Summary: Postinstall scripts are failable, fail during KDE netinst (due to dependency loop most likely) Product: Fedora Version: rawhide Hardware: All OS: All Status: NEW Component: xorg-x11-fonts Severity: urgent Assignee: xgl-maint(a)redhat.com Reporter: awilliam(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: airlied(a)redhat.com, ajax(a)redhat.com, caillon+fedoraproject(a)gmail.com, caolanm(a)redhat.com, fonts-bugs(a)lists.fedoraproject.org, jglisse(a)redhat.com, negativo17(a)gmail.com, rhughes(a)redhat.com, rstrode(a)redhat.com, sandmann(a)redhat.com, xgl-maint(a)redhat.com Target Milestone: --- Classification: Fedora In current Fedora Rawhide, KDE network installs fail with a scriptlet error in an xorg-x11-fonts subpackage: 16:36:01,304 INF dnf.rpm: mkfontscale: error while loading shared libraries: libfreetype.so.6: cannot open shared object file: No such file or directory warning: %post(xorg-x11-fonts-ISO8859-1-100dpi-7.5-27.fc34.noarch) scriptlet failed, exit status 127 16:36:01,310 ERR dnf.rpm: Error in POSTIN scriptlet in rpm package xorg-x11-fonts-ISO8859-1-100dpi Dependencies should be in place, AFAICT: xorg-x11-fonts subpackages require 'mkfontdir', which is in the same package as mkfontscale (xorg-x11-font-utils) and that package requires libfreetype.so.6. What's likely happening is a dependency loop that dnf has to break somehow. This isn't uncommon on initial install, something like A requires B requires C requires A, and in order to do anything, dnf has to pick *some* dependency to disregard. Probably because of some loop like this, it's ordering install of xorg-x11-fonts-ISO8859-1-100dpi before install of freetype, and so its %post script fails. We could look for and try to fix that loop, but note the packaging guidelines state: "All scriptlets MUST exit with the zero exit status. Because RPM in its default configuration does not execute shell scriptlets with the -e argument to the shell, excluding explicit exit calls (frowned upon with a non-zero argument!), the exit status of the last command in a scriptlet determines its exit status. Most commands in the snippets in this document have a “|| :” appended to them, which is a generic trick to force the zero exit status for those commands whether they worked or not. Usually the most important bit is to apply this to the last command executed in a scriptlet, or to add a separate command such as plain “:” or “exit 0” as the last one in a scriptlet. Note that depending on the case, other error checking/prevention measures may be more appropriate. Non-zero exit codes from scriptlets can break installs/upgrades/erases such that no further actions will be taken for that package in a transaction (see Ordering), which may for example prevent an old version of a package from being erased on upgrades, leaving behind duplicate rpmdb entries and possibly stale, unowned files on the filesystem. There are some cases where letting the transaction to proceed when some things in scriptlets failed may result in partially broken setup. It is however often limited to that package only whereas letting a transaction to proceed with some packages dropped out on the fly is more likely to result in broader system wide problems." https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_sy... basically, by policy scriptlets should be written to return 0 even if they don't work. These scriptlets aren't respecting that. Given that not running mkfontdir likely doesn't have any calamitous consequences, I think it would make sense to go with the guidelines and amend all the scriptlets to add `|| :` at the end (which will cause them to exit 0 even if the command failed). -- You are receiving this mail because: You are on the CC list for the bug.

1 year, 11 months

1
4
0 / 0

[Bug 1580458] [ta_IN] Error in latest Tamil ttf

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1580458 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|34 |rawhide -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1580458

1 year, 11 months

1
0
0 / 0

[Bug 1076190] Rendering of Unicode tie bars could be improved

by bugzilla＠redhat.com

https://bugzilla.redhat.com/show_bug.cgi?id=1076190 Jens Petersen <petersen(a)redhat.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|34 |rawhide Keywords| |FutureFeature -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1076190

1 year, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts-bugs May 2022