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>
> 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)
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
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
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 ?
That re-write draft as included does not address PDF
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 \
one will get a 'missfont.log' as to an inability to embed a
required font, 'required' for completeness for portability
See the discussion at:
and its practical implication is discussed at:
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]
pull requirement: All fonts should be converted
to outlines and embedded
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 &
[ 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 ?
-- Russ herrold
A fonts packaging policy rewrite proposal has been pushed to FPC today:
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
– 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
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
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,
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