fontconfig: Support multiple property values in matching code

[dmik]

In fontconfig, according to the docs, each property of a pattern (e.g. FC_FAMILY) may have more than one value (i.e. something like WarpSans plus Helv) and both of these values will be used when matching the pattern with some font set (using e.g. FcFontMatch). It looks to me that our old, r927 code only supported a single value per pattern property. And our OS/2 applications using fontconfig are aware of this fact and never supply it with multi-value patterns (or at least we don't notice any problems when they do).

However, the update of fontconfig to the newest version 2.11.94 in r1170 (and above) brought the upstream FcPattern implementation which supports multi-values and also some matching code (e.g.FcFontSetSort) that utilizes these multi-values. OTOH, there is still some old OS/2 matching code like FcFontMatch (actually, all code in fontconfig.c) that uses only the first value of each property. This creates an obvious inconsistency. We should fix that and make our OS/2 code support multi-values as well (perhaps, by borrowing parts from the upstream fontconfig.c implementation).

[dmik]

There is at least one known case that was broken after update. WhenFcFontSort can't find anything close to the requested pattern, it tries to fall back to DEFAULT_SERIF_FONT (which is supposed to be always installed). But it does so by appending a new FC_FAMILY value to the one that was not found instead of replacing it (or at least prepending). As a result, the second FcFontMatch call with the appended default font would also fail since it were still trying to find only the first family (which it already failed to find). It worked in r927 and before because we had a custom FcPattern implementation that supported only one value and any attempt to append a new one would simply overwrite the previous one.

In particular, this made the new Firfox 38 crash after switching it to pango font library (see ​https://github.com/bitwiseworks/mozilla-os2/issues/115#issuecomment-158112019) because the pango code path lacked the hard coded Workplace Sans for WarpSans substitution and when it tried to find WarpSans, the FcFontSort code was triggered but the default font fallback didn't work causing the call chain to return nsnull to Firefox instead of some fallback font.

I fixed this regression in r1181, now Firefox doesn't crash with the stock pango code (it has some charset problems though but that may also be some fontconfig update regression — we needed this update to make the pango code compile BTW).

[dmik]

This is actually not relevant any more as we switched to a complete upstream version of fontconfig 2.11.94 which already provides all of the above (and much more). See #77.