[Fontconfig] Difficulty finding a font file through the libraries

Sun Nov 7 06:42:19 UTC 2021

> On Oct 31, 2021, at 00:46, Michael Brennen <michael at fishnet.us <mailto:michael at fishnet.us>> wrote:
> 
> I now understand both why gs is not printing FC debug messages and why it is not matching the same fonts that fc-match does.
> 
> I downloaded the Centos 7 ghostscript source package tonight and found that the only part of fontconfig that it uses is the subset of routines to collect the names of fonts available. It adds the FC font list to its own set of fonts, and it then does its own font searching and matching.
> 
> So the font matching problem is somewhere in gs, not fontconfig. Thanks for the responses; I hope knowing that gs’s use of fontconfig is limited comes in useful.

This thing got under my skin, and I wanted to find it. I did.

In an init routine gs pulls in all the fonts into an array; it then iteratively calls a routine to process through the array one font at a time, returning 1 when a font has been processed. When it is through it returns 0, and once that happens the iterator will not be called again.

Significantly, the iterator also return 0 on errors, and it finds two, both because the font weight did not match what was expected. Once it finds a font with an error processing stops, and everything unprocessed in the list is abandoned. That is why some fonts were not being found; they just happened to fall after the first error.

I rebuilt gs from its source package and made a few debug changes to find all this. After commenting the 0 returns on errors, the process runs to completion and the desired font is found.

The FC routine called from gs to get the weight is this:

     result = FcPatternGetInteger (font, FC_WEIGHT, 0, &weight_fc);

My debug messages, slightly modified from the gs debug messages:

FC_WEIGHT failed to match on Bahnschrift (and Skia)
FC_WEIGHT failed to match on 32764

weight_fc is an int where the result is stored; that is what is showing 32764 upon return.

I don’t know the significance of the weight reported as 32764 (0x7FFC), or where it might be found in the font file. fc-match reports different weight numbers, 80 for Bahnschrift and 0.5 for Skia. These two fonts errored with the weight = 0x7ffc; I will post the output of fc-match for one below, for what it may be worth.

From the fontconfig source, it looks like the weight must be between 1 and 1000; that would explain the error, but not why these two fonts have such a strange number.

I quickly become tangled in FC’s fc_pat.c, which is where most of this seems to happen. I am not sure what an ELT is (element?) is; I found where it is retrieved by indexing into some data structure, but I don’t know what that is.

So my question is, what might be happening with these two fonts? Does anyone knowledgeable about FC recognize why the weight would be reported wrongly for these two fonts?

Thanks much in advance for any help you can offer.

   -- Michael

# fc-match -v Bahnschrift
Pattern has 36 elts (size 48)
	family: "Bahnschrift"(s)
	familylang: "en"(s)
	style: "Regular"(s)
	stylelang: "en"(s)
	fullname: "Bahnschrift"(s)
	fullnamelang: "en"(s)
	slant: 0(i)(s)
	weight: 80(f)(s)
	width: 100(f)(s)
	size: 12(f)(s)
	pixelsize: 12.5(f)(s)
	foundry: "MS  "(w)
	hintstyle: 1(i)(w)
	hinting: True(s)
	verticallayout: False(s)
	autohint: False(s)
	globaladvance: True(s)
	file: "/var/www/ext/resources/fonts/bahnschrift.ttf"(w)
	index: 0(i)(w)
	outline: True(w)
	scalable: True(w)
	dpi: 75(f)(s)
	scale: 1(f)(s)
	charset:
	0000: 00000000 ffffffff ffffffff 7fffffff 00000000 ffffffff ffffffff ffffffff
	0001: cfcffcff 7ec3cccf cfff3dfe 7f0ffc3f 0317c642 009d8003 20000000 00000000
	0002: 0f000000 00000000 0ad80000 00000000 00000000 18000000 3b0002c0 00000000
	0003: 08001fdf 002001c8 00000020 fcff0000 ffffd7f0 fffffffb ffffffff ffffffff
	0004: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
	0005: 00000000 00000030 00000000 00000000 00000000 00000000 00000000 00000000
	001e: 00000000 00000000 00000000 0000000c 00000000 03000003 00003c00 00000030
	0020: 77380000 06010047 00000000 00110000 00000000 7fffffff 00000000 00000000
	0021: 00400000 00080004 00000000 00000000 00000000 00000000 00000000 00000000
(w)
	lang: aa|ab|av|ay|az-az|ba|be|bg|bi|bin|br|bs|bua|ce|ch|chm|co|cs|cu|cv|da|de|el|en|es|et|eu|fi|fj|fo|fr|fur|fy|gd|gl|gv|ha|haw|ho|hr|hu|ia|ig|id|ie|ik|io|is|it|kaa|kk|kum|kv|ky|lb|lez|ln|lt|lv|mg|mh|mk|mo|mt|nb|nds|nl|nn|no|nr|nso|oc|om|os|pl|pt|rm|ro|ru|sah|sel|sh|sk|sl|sm|sma|smj|smn|so|sq|sr|ss|st|sv|sw|tg|tk|tl|tn|to|tr|ts|tt|tyv|uk|uz|vo|vot|wa|wen|wo|xh|yap|zu|an|crh|csb|fil|hsb|ht|jv|kj|ku-tr|kwm|lg|li|mn-mn|ms|ng|pap-an|pap-aw|rn|rw|sc|sg|sn|su|ty|za(s)
	fontversion: 131072(i)(s)
	capability: "otlayout:DFLT otlayout:latn"(w)
	fontformat: "TrueType"(w)
	embeddedbitmap: True(s)
	decorative: False(s)
	namelang: "en"(s)
	prgname: "fc-match"(s)
	postscriptname: "Bahnschrift"(w)
	color: False(w)
	symbol: False(s)
	variable: False(s)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/fontconfig/attachments/20211107/69c75154/attachment-0001.htm>