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,
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,
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
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,
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
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.
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 -
R P Herrold