Re: [Fontconfig] fontconfig priority management

[Nicolas Mailhot]

Le mardi 16 octobre 2018 à 22:03 -0400, Jerry Casiano a écrit :

Hi,

>  A link to the previous discussion? which gives this some context
> would
>  be appreciated. 
I pretty much quoted Akira's initial message entirely ;). Since we've
both been at it for a long time, some things are not overly detailed and
just alluded at minimally.

Regards,

-- 
Nicolas Mailhot

[Fontconfig] fontconfig priority management

[Nicolas Mailhot]

Le mercredi 17 octobre 2018 à 08:31 +0200, Nicolas Mailhot a écrit :
>  Le mardi 16 octobre 2018 à 22:03 -0400, Jerry Casiano a écrit :
>  
>  Hi,
>  
>  > A link to the previous discussion? which gives this some context
>  > would
>  > be appreciated.
>  
>  I pretty much quoted Akira's initial message entirely ;). Since we've
>  both been at it for a long time, some things are not overly detailed
>  and just alluded at minimally. 
In case that was not clear: if you have a particular question just ask!
We're not being cryptic on purpose.

Regards,

-- 
Nicolas Mailhot

fontconfig priority management

[R P Herrold]

On Wed, 17 Oct 2018, Nicolas Mailhot wrote:

>  In case that was not clear: if you have a particular question just
> ask!
>  We're not being cryptic on purpose. 
well, I am wrestling with a 'priority' issue (I think) 
presently.  Reading the man page for: fc-match it asserts it:

	-s     Displays sorted list of best matching fonts


assumedly: 
	using  the  normal fontconfig matching rules to find 
	the best font available

whatever those are.  I have read files, and do not see any 
obvious specification of 'priorities' 


Installed are:

[herrold@centos-7 unsorted]$ rpm -qa | sort | grep font 
abattis-cantarell-fonts-0.0.25-1.el7.noarch
adobe-source-code-pro-fonts-2.030.1.050-5.el7.noarch
bitmap-lucida-typewriter-fonts-0.3-21.el7.noarch
dejavu-fonts-common-2.33-6.el7.noarch
dejavu-lgc-sans-fonts-2.33-6.el7.noarch
dejavu-lgc-sans-mono-fonts-2.33-6.el7.noarch
dejavu-sans-fonts-2.33-6.el7.noarch
dejavu-sans-mono-fonts-2.33-6.el7.noarch
dejavu-serif-fonts-2.33-6.el7.noarch
fontawesome-fonts-4.1.0-1.el7.noarch
fontawesome-fonts-web-4.1.0-1.el7.noarch
fontconfig-2.10.95-11.el7.x86_64
fontconfig-devel-2.10.95-11.el7.x86_64
fontforge-20150824-1.orc7.x86_64
fontpackages-devel-1.44-8.orc7.noarch
fontpackages-filesystem-1.44-8.orc7.noarch
fonttools-2.4-3.el7.x86_64
ghostscript-fonts-5.50-37.orc7.noarch
google-crosextra-caladea-fonts-1.002-0.4.20130214.el7.noarch
google-crosextra-carlito-fonts-1.103-0.2.20130920.el7.noarch
google-roboto-slab-fonts-1.100263-0.3.20150923git.el7.noarch
hack-fonts-2.018-1.el7.centos.noarch
lato-fonts-2.010-3.el7.noarch
levien-inconsolata-fonts-1.01-12.el7.centos.noarch
liberation-fonts-1.07.2-16.el7.noarch
liberation-fonts-common-1.07.2-16.el7.noarch
liberation-mono-fonts-1.07.2-16.el7.noarch
liberation-narrow-fonts-1.07.2-16.el7.noarch
liberation-sans-fonts-1.07.2-16.el7.noarch
liberation-serif-fonts-1.07.2-16.el7.noarch
libfontenc-1.1.3-3.el7.x86_64
libfontenc-devel-1.1.3-3.el7.x86_64
libreoffice-opensymbol-fonts-5.3.6.1-10.el7.noarch
libXfont-1.5.2-1.el7.x86_64
libXfont2-2.0.1-2.el7.x86_64
libXfont2-devel-2.0.1-2.el7.x86_64
libXfont-devel-1.5.2-1.el7.x86_64
lyx-fonts-2.2.3-1.el7.noarch
mathjax-ams-fonts-2.4.0-1.el7.noarch
mathjax-caligraphic-fonts-2.4.0-1.el7.noarch
mathjax-fraktur-fonts-2.4.0-1.el7.noarch
mathjax-main-fonts-2.4.0-1.el7.noarch
mathjax-math-fonts-2.4.0-1.el7.noarch
mathjax-sansserif-fonts-2.4.0-1.el7.noarch
mathjax-script-fonts-2.4.0-1.el7.noarch
mathjax-size1-fonts-2.4.0-1.el7.noarch
mathjax-size2-fonts-2.4.0-1.el7.noarch
mathjax-size3-fonts-2.4.0-1.el7.noarch
mathjax-size4-fonts-2.4.0-1.el7.noarch
mathjax-typewriter-fonts-2.4.0-1.el7.noarch
mathjax-winchrome-fonts-2.4.0-1.el7.noarch
mathjax-winie6-fonts-2.4.0-1.el7.noarch
msttcore-fonts-installer-2.6-1.noarch
open-sans-fonts-1.10-1.el7.noarch
stix-fonts-1.1.0-5.el7.noarch
stix-math-fonts-1.1.0-5.el7.noarch
texlive-amsfonts-svn29208.3.04-38.el7.noarch
texlive-collection-fontsrecommended-svn28082.0-38.20130427_r30134.el7.noarch
texlive-fontbook-svn23608.0.2-38.el7.noarch
texlive-fontspec-svn29412.v2.3a-38.el7.noarch
texlive-fontwrap-svn15878.0-38.el7.noarch
texlive-latex-fonts-svn28888.0-38.el7.noarch
texlive-metafont-bin-svn26912.0-38.20130427_r30134.el7.x86_64
texlive-metafont-svn26689.2.718281-38.el7.noarch
texlive-pxfonts-svn15878.0-38.el7.noarch
texlive-txfonts-svn15878.0-38.el7.noarch
texlive-xetexfontinfo-svn15878.0-38.el7.noarch
urw-base35-bookman-fonts-20170801-11.orc7.noarch
urw-base35-c059-fonts-20170801-11.orc7.noarch
urw-base35-d050000l-fonts-20170801-11.orc7.noarch
urw-base35-fonts-20170801-11.orc7.noarch
urw-base35-fonts-common-20170801-11.orc7.noarch
urw-base35-gothic-fonts-20170801-11.orc7.noarch
urw-base35-nimbus-mono-ps-fonts-20170801-11.orc7.noarch
urw-base35-nimbus-roman-fonts-20170801-11.orc7.noarch
urw-base35-nimbus-sans-fonts-20170801-11.orc7.noarch
urw-base35-p052-fonts-20170801-11.orc7.noarch
urw-base35-standard-symbols-ps-fonts-20170801-11.orc7.noarch
urw-base35-z003-fonts-20170801-11.orc7.noarch
xorg-x11-fonts-100dpi-7.5-9.el7.noarch
xorg-x11-fonts-75dpi-7.5-9.el7.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.5-9.el7.noarch
xorg-x11-fonts-ISO8859-1-75dpi-7.5-9.el7.noarch
xorg-x11-fonts-misc-7.5-9.el7.noarch
xorg-x11-fonts-Type1-7.5-9.el7.noarch
xorg-x11-font-utils-7.5-20.el7.x86_64
[herrold@centos-7 unsorted]$ 


and the 'best' matches for 'Times Roman' are:

[herrold@centos-7 ~]$ fc-match -s "Times" | head -n 5 
NimbusRoman-Regular.otf: "Nimbus Roman" "Regular"
times.ttf: "Times New Roman" "Normal"
LiberationSerif-Regular.ttf: "Liberation Serif" "Regular"
DejaVuSerif.ttf: "DejaVu Serif" "Book"
DejaVuSerif-Bold.ttf: "DejaVu Serif" "Bold"
[herrold@centos-7 ~]$ 
	


But something is missing, I believe, formerly carried in a 
pre-refactoring urw- font package:

This is one candidate PDF which provokes the stderr messages 
below:

	http://gallery.herrold.com/stuff/ibm-rest-cloud-api-20180727.pdf

[herrold@centos-7 unsorted]$ file ibm-rest-cloud-api-20180727.pdf
ibm-rest-cloud-api-20180727.pdf: PDF document, version 1.5


[herrold@centos-7 unsorted]$ xpdf 
ibm-rest-cloud-api-20180727.pdf 1> /dev/null 
Config Error: No display font for 'Courier'
Config Error: No display font for 'Courier-Bold'
Config Error: No display font for 'Courier-BoldOblique'
Config Error: No display font for 'Courier-Oblique'
Config Error: No display font for 'Helvetica'
Config Error: No display font for 'Helvetica-Bold'
Config Error: No display font for 'Helvetica-BoldOblique'
Config Error: No display font for 'Helvetica-Oblique'
Config Error: No display font for 'Symbol'
Config Error: No display font for 'Times-Bold'
Config Error: No display font for 'Times-BoldItalic'
Config Error: No display font for 'Times-Italic'
Config Error: No display font for 'Times-Roman'
Config Error: No display font for 'ZapfDingbats'


===========

I would _like_ to have the old URW fontset back, 
unsatisfactory as it is considered in modern practice, present 
and working, but at whatever the lowest preferance priority 
is, so that I have the old PDF base series exact matched

I do not attach, as it contains Personally Identificable 
Information, a form from the US Social Security 
Administration, and another from an insurance carrier I use, 
and neither is useful in Linux.  See a PII sanitized 
screenshot:

	http://gallery.herrold.com/stuff/nasty-laying-PDF.png

I am happy to file a bug, either in the Red Hat tracker or 
elsewhere as needed, and to reply to any questions

Please let me know

-- Russ herrold

fontconfig priority management

[Nicolas Mailhot]

Le mercredi 17 octobre 2018 à 14:03 -0400, R P Herrold a écrit :

>  But something is missing, I believe, formerly carried in a 
>  pre-refactoring urw- font package:
>  
>  This is one candidate PDF which provokes the stderr messages 
>  below: 
Hi,

I haven't used xpdf for years (I understand some poor people need it for
pdf forms and such things). IMHO you just hit part of the legacy xpdf
codebase, that was not properly ported to fontconfig, and does not use
fontconfig to fallback to other fonts if the font name it wants does not
exist on system.

Somewhere in the xpdf codebase, you have hardcoded font names, and the
urw rework finally changed those slightly, and xpdf is too dumb to query
fontconfig to get the next best matching font.

That or a bit of xpdf is still unable to process Opentype fonts in 2018,
and will fail if there is no Postscript 1 font on system for the
standard PS font families.

Either way the tech fontconfig and OpenType replace is slowly going
away, so apps that didn't finish their port to fontconfig and Opentype
will start failing one after the other in the next years.

Regards,

-- 
Nicolas Mailhot

fontconfig priority management

[R P Herrold]

On Fri, 19 Oct 2018, Nicolas Mailhot wrote:

>  Le mercredi 17 octobre 2018 à 14:03 -0400, R P Herrold a écrit :
>  
>  > But something is missing, I believe, formerly carried in a 
>  > pre-refactoring urw- font package:
>  > 
>  > This is one candidate PDF which provokes the stderr messages 
>  > below:
>  
>  Hi,
>  
>  I haven't used xpdf for years (I understand some poor people need it for
>  pdf forms and such things) 
I am not sure how that indicates 'poor' ... 'unfortunate', 
perhaps, as that is indeed the use case I face, for government 
PDF fillable forms, and insurance company PDF forms

>  That or a bit of xpdf is still unable to process Opentype fonts in
> 2018,
>  and will fail if there is no Postscript 1 font on system for the
>  standard PS font families. 
I suspect the latter as the problem began after urw-base35 
displaced the former (Type 1 bearing) urw-fonts, and thus my 
wish for:

>  I would _like_ to have the old URW fontset back, 
>  unsatisfactory as it is considered in modern practice, 
>  present and working, but at whatever the lowest preferance 
>  priority is, so that I have the old PDF base series exact 
>  matched 
It seems to be about 5 MBy in size. But bigger font sets seem 
to be present and were dragged in by some pacakge as listed in 
installed as a dependency:

$ rpm -qa --qf "%{size} %{name} \n" | grep "fonts" | sort -n
 ...
5395167 dejavu-sans-fonts 
		by: python-matplotlib, gnuplot, and libreoffice-core
6211653 texlive-amsfonts 
		by: lots of LaTeX packages
7179431 xorg-x11-fonts-misc 
		by: xosd
11442067 lato-fonts 
		by: python2-sphinx_rtd_theme

and the user experience is ... horrible.


Actually, and frankly, it was disabling and non-usable -- see 
the prior email from me with screen shots.  As a work-around, 
I initiall solved the problem by doing the work on a Windows 
10 box, and an OS/X install

I see the discussion at:
	https://www.adobe.com/products/type/opentype/opentype-T1-faq.html

and understand it, but the Real World still has documents 
bearing this stuff, and one needs to see it to do real work

[I think, also, it is not unreasonable to attend to getting 
xpdf quieter, and using the new namings ... I will look]


Is having the Type 1 font available but of a lowest priority,
an unreasonable request?



(FWIW: I later worked around the issue locally by building and 
installing a fork: urw-fonts-local from an ancient
	retired/netwinder/SRPMS/nw/9/9/urw-fonts-2.0-29.src.rpm

	http://gallery.herrold.com/stuff/urw-fonts.spec

and now with the test file:
	
	http://gallery.herrold.com/stuff/ibm-rest-cloud-api-20180727.pdf

only have as error noise:

Config Error: No display font for 'ZapfDingbats'

seemingly a proprietary Adobe (pissobly ITC) Type 1 only font

)

-- Russ herrold

fontconfig priority management

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 15:02 -0400, R P Herrold a écrit :
>  On Fri, 19 Oct 2018, Nicolas Mailhot wrote:
>  
>  > Le mercredi 17 octobre 2018 à 14:03 -0400, R P Herrold a écrit :
>  
>  I am not sure how that indicates 'poor' ... 'unfortunate', 
>  perhaps, as that is indeed the use case I face, for government 
>  PDF fillable forms, and insurance company PDF forms
>  
>  > That or a bit of xpdf is still unable to process Opentype fonts in
>  2018,
>  > and will fail if there is no Postscript 1 font on system for the
>  > standard PS font families.
>  
>  I suspect the latter as the problem began after urw-base35 
>  displaced the former (Type 1 bearing) urw-fonts, and thus my 
>  wish for: 
Stop wishing for that, there's no technical reason at all in 2018 to use
PS1 fonts over Opentype ones. OpenType CFF (.otf) fonts have the very
same technical format for curves as PostScript 1 fonts, but the metadata
around those curves is vastly more complete and solves real-world
problems identified since PS 1 fonts were defined.

The reason the fonts you list are more bulky is not some problem in
their format, they're more bulky because they have more encoding
coverage.

PS1 is deader than dead, fontconfig still supports it but apps like
LibreOffice have started rejecting it upstream even when fontconfig
presents it (the app writers are fed up with writing workarounds to
compensate for the holes in the PS1 metadata).

So Fedora, as a distribution, has no interest in shipping PS1 fonts
anymore. They don't bring any value over the equivalent OTF fonts, they
are inherently dangerous due to the PS1 format deficiencies, they result
in bugs when an app is confused in selecting them over their OTF
equivalent. If you want to expend some lobbying energy, get xpdf and
other stragglers to fix their fontconfig/opentype support. You won't
stem the fontconfig/opentype tide. It had 15 years to build up both in
the FLOSS and proprietary world. It's way too late to rewrite history
now.

-- 
Nicolas Mailhot

fontconfig priority management

[Nicolas Mailhot]

Anyway I took the time to investigate

https://forum.xpdfreader.com/viewtopic.php?t=36

xpdf is definitely *not* using fontconfig, it relies on hardcoded font
locations, you probably just need to adapt them to the new urw
locations.

And then you will hit PS1 vs OpenType if this part of xpdf is not ready
for 2000 either.

-- 
Nicolas Mailhot