Owen and I were chatting on IRC yesterday about the problem we've all see
with fontconfig -- a user in an 'en' locale will get really bad choices
for languages that use non-Latin scripts. One obvious example is when
displaying a mixed English/Arabic document -- the 'en' locale forces the
selection of fonts that support 'en' even for Arabic parts of the document.
I came up with a suggestion to fix FcFontSort which seems to help in this
situation, although it is rather specific to the language matching
features. I think that's probably OK as FcFontSort already is rather
focused on coverage.
The idea is to first sort including FC_LANG, then pull off the head of
that list until all of the languages in the pattern FC_LANG are supported.
Then, re-sort the remaining elements ignoring FC_LANG. Return the whole
list.
The result will be:
1) Strongly bound family names
2) A minimal set of fonts as required to support FC_LANG
3) The rest of the fonts sorted according to the <alias> entries
Owen pointed out one problem with this plan -- Pango is currently dropping
fonts from the list which don't include good layout information if fonts
further down do include that. Re-sorting will mean that Pango may find
fonts inappropriate for a particular language before it finds the right
ones:
{ar without OT tables} {fa with OT tables} {ar with OT tables}
In this case, Pango will end up using the farsi font to display arabic.
Really, the right solution is to order the aliases so that the ar font
with OT tables appears first, or alternatively include OT table
information in fontconfig and have Pango include requests for that in the
sorting information. The latter is apparantly "hard" to do in Pango.
However, this change doesn't really break things that aren't broken -- the
font elision step in FcFontSort will likely drop the {ar with OT tables}
font in any case, even if it is sorted before {fa with OT tables}.
So, this change makes Pango no worse off :-)
Comments? Sample code?
-keith
