>> By the way, this behaviour is undocumented in the `fonts.conf` >> manpage. > > Sure. This can be definitely improved. Great! It is probably sufficient to mention that `<acceptfont>` and `<rejectfont>` are only influenced by `<match target="scan">` and not by the targets 'font' and 'pattern'. By the way, why is that so? It looks like an artificial limitation, and as my real-world example shows it can cause problems. > that said: > > --- quoted from doc > Fonts matched by an rejectfont element are "blacklisted"; such fonts are > excluded from the set of fonts used to resolve list and match requests > --- end > > And "font" target is applied to the result on matching. So it may not > be that hard to imagine matching will be processed after filtering by > acceptfont/rejectfont. Believe me, it is that hard to imagine :-) >> I answered too quickly. It apparently doesn't work for LilyPond, >> which uses an application-specific Fontconfig configuration file. In >> other words, I need a method to reject fonts with index > 0xFFFF that >> doesn't need rescanning of all fonts in the OS, something like > > They don't have a sort of 50-user.conf loaded? No. LilyPond uses the fonts from the OS but can't handle Variation Fonts – for the default output backend it has to embed fonts in an intermediate PS file, and PostScript doesn't support VFs. >> Any idea how this could be achieved? > > Unfortunately not because such conditions can't be represented in > FcPattern. In other words, there is no solution right now, correct? >> If it weren't for backward compatibility I would simply ask to add a >> new property `namedinstance` that gets set as soon as the font index >> is larger than 0xFFFF... > > That would be possible. please file an rfe to > https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues Done: https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/362 Werner
