fonts March 2020

fonts@lists.fedoraproject.org

4 participants
4 discussions

Add Persian fonts
by mohamad moghadam 28 Mar '20

28 Mar '20

I want to add several Persian font to fedora repository. How to do it? fonts in github : https://github.com/rastikerdar/vazir-font https://github.com/rastikerdar/samim-font https://github.com/rastikerdar/shabnam-font https://github.com/rastikerdar/sahel-font https://github.com/rastikerdar/parastoo-font https://github.com/rastikerdar/gandom-font https://github.com/rastikerdar/nahid-font https://github.com/rastikerdar/tanha-font

3 2

Re: [Rd] Plotmath on Fedora 31 broken with with pango >= 1.44 - workarounds?
by Nicolas Mailhot 25 Mar '20

25 Mar '20

Le mercredi 25 mars 2020 à 11:28 +0100, Iñaki Ucar a écrit : > On Wed, 25 Mar 2020 at 01:14, Gavin Simpson <ucfagls(a)gmail.com> > wrote: Hi, > Adding devel(a)lists.fp.o to CC. A workaround is to avoid using PS > fonts for symbols. PS fonts are dead mid-term everywhere, and already forbidden in new Fedora font packages (because we are somewhat leading edge, but not as much as people think) https://docs.fedoraproject.org/en-US//packaging-guidelines/FontsPolicy/#_fo… PS font users need to switch to OpenType fonts or work with their prefered font upstream to convert in modern well supported formats (font format wars have endend last millenium, even before the browser wars ended, it’s long past time to deprecate the losers). That’s normal IT format obsolescence. That being said, that’s not what is happening here. R brought this all on itself by hardcoding a Windows-only “Symbol” font family name in its default conf. Linux systems are UTF-8 by default for ~20 years now, they don’t need the forcing of magic font families to handle symbols not present in the 8-bit legacy Windows encodings. The actual effect of this conf is not the selection of font files with special and unusual symbols. It is to priorize fonts that match the "Symbol" magic name. And those fonts are few and crumbling on Linux systems, because no one has needed to bother with them since Linux switched to UTF-8 last millenium. Just stop using “Symbol” in R and things will work a lot better. Alternatively, prepare to maintain the “Symbol” aliasing stack in fontconfig (and fight with wine for it), because *no* *one* *else* *cares* about this legacy Windows-specific stuff. Fontconfig upstream already told this to R users in its own issue tracker. Regards, -- Nicolas Mailhot

1 0

Embedded font support for PDFs is lacking; response to: Fonts packaging guidelines change status
by R P Herrold 16 Mar '20

16 Mar '20

Subject: Fonts packaging guidelines change status On Sat, 7 Mar 2020, Nicolas Mailhot wrote: > WHAT IS IT ALL ABOUT > > On 2020-02-13, FPC approved a rewrite of our fonts packaging > guidelines. and again that was published on the 14th removing some top matter through the Section mark: NEW PACKAGES STILL PENDING REVIEW, and advancing PR status on a couple of fonts But this question in the fonts-list was not addressed (see the bottom of this resend to include the devel list): Is a formal 'bug' needed to track this ? Background: That re-write draft as included does not address PDF portability The Fedora most recent prior approach on fonts neglected explicitly supporting the need of Latex chain created documents for type 1 fonts to be embedded in PDFs. From raising this issue previously, it is my understanding that Type 1 fonts are felt to not screen render as well as some later alternatives, but when it comes to generating a Portable Document to reliably render 'the same', one HAS to carry and prefer embedded fonts when present Detection of the issue, and Problem summarized: When one is missing fonts, and runs something like: dvips -t letter -Ppdf -G0 -j0 mypaper.dvi \ -o mypaper.ps one will get a 'missfont.log' as to an inability to embed a required font, 'required' for completeness for portability purposes See the discussion at: https://helpx.adobe.com/acrobat/using/pdf-fonts.html and its practical implication is discussed at: https://blogs.adobe.com/acrolaw/2007/11/pdf_creation_and_font_embedding/ The TL;DR takeaway is: The USPTO requires that PDF must be: Acrobat 4 (PDF 1.3) or higher (See note at end of article) No larger than 8.5? by 11? or A4 page size Have all fonts embedded and subset It is not JUST preparation of documents for filing there, but also for submitting 'camera ready PDF copy' to Lulu print on demand. Lulu is a child of Robert Young [a serial entrepreneur who is best known for founding Red Hat Inc] https://connect.lulu.com/en/discussion/33148 https://connect.lulu.com/en/discussion/33681/pdf-creation-settings-how-can-… pull requirement: All fonts should be converted to outlines and embedded Way forward: There is a collection of 13 fonts provided under a freely reproducible license from Adobe, known as the Base 13 fonts - Courier, Courier-Bold, Courier-Oblique & Courier-BoldOblique - Times-Roman , Times-Bold , Times-Italic & Times-BoldItalic - Helvetica, Helvetica-Bold, Helvetica-Oblique & Helvetica-BoldOblique - Symbol [ but not: - ZapfDingbats ] I understand that they were removed from Fedora, as the Base 13 are Type 1 fonts .... but dang it, at least for purposes of completeness to be able to generate legal documents, and to permit me to continue to use FOSS tools to publish for fulfillment at Lulu, can we get these Type 1 fonts back, regardless of slight risk of aesthetic discontent ? Is a formal 'bug' needed to track this ? Thank you -- Russ herrold

1 0

Fonts packaging policy rewrite proposal
by Nicolas Mailhot 14 Mar '20

14 Mar '20

Hi, A fonts packaging policy rewrite proposal has been pushed to FPC today: https://pagure.io/packaging-committee/pull-request/934 It should be clearer, more opinionated, and take into account: – updates of The OpenType standard – variable fonts – web fonts – upstream depreciation of non OpenType formats: final stages of the Harfbuzz consolidation decided at the 2006 Text Layout summit https://www.freedesktop.org/wiki/TextLayout/ – appstream & fonts – weak dependencies – and probably more I forget here It is based on the new fonts-rpm-macros project for automation: This project builds on tooling enhancements in redhat-rpm-config and rpm itself, done during the past two years for the Forge and Go sets of packaging macros. It started 2 years ago as a fork of fontpackages, which is the core of our current fonts packaging guidelines. It will require putting the fonts-srpm-macros package in the default build root, like is done for other domain-specific packaging macro sets. Major additions: – better documentation (clearer and more complete) – better automation (less packager hassle for better and more complete results) Major removals: – tools and scripts – fixing metadata with ttname Mostly because no one seems willing to maintain those scripts, or port ttname to python 3. https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/ showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex. Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines. Regards, -- Nicolas Mailhot

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts March 2020