[Fontconfig] Re: Bug with fc-match

[Patrick Lam]

Mike FABIAN wrote:

> I.e. there are both outline and bitmap versions of "Bitstream Charter"
> available. fc-list works fine, but trying to match the outline
> versions with fc-match doesn't work, it always matches the bitmap
> versions:
> 
> mfabian at magellan:~$ fc-match  "Bitstream Charter:style=Regular:outline=true"
> charR12.pcf.gz: "Bitstream Charter" "Regular"
> mfabian at magellan:~$ fc-match  "Bitstream Charter:style=Regular:scalable=true"
> charR12.pcf.gz: "Bitstream Charter" "Regular"
> mfabian at magellan:~$

Ok, here's what I've discovered so far:

* scalable=true isn't recognized by fc-match as a matching criterion.
(_FcMatchers in fcmatch.c:187 is the list of matchers)

* FcDefaultSubstitute adds a bunch of criteria to the pattern which
cause the outline version to be rejected.

* The criterion which causes the outline version to be rejected is
FC_PIXEL_SIZE.  FcDefaultSubstitute notes that we don't specify a
pixelsize, so it computes one.  (fcdefault.c lines 131-1515).
Furthermore, FC_PIXEL_SIZE gets put before FC_OUTLINE, so that it
eliminates the outline version before FC_OUTLINE can work.

* Since the outline font doesn't have an FC_PIXEL_SIZE element, then it
doesn't get the v = v * 100 + v1_offset, which causes it to have a lower
score than the bitmap fonts, which is why it gets rejected.

* The pattern elements are sorted to enable binary search on pattern
elements, which is why pixelsize comes before outline.  In fact, the
matching pattern never has FcPatternGet called on it (it's only accessed
sequentially), so we don't quite need to sort elements there, but that
seems to enable a whole bunch of unsortedness bugs to come up.

I don't know what the correct solution to this problem is, but that's
what happening.  Perhaps we shouldn't sort patterns used for matching.

pat