The conditional '%{?elt1,elt2,!elt3{expr1}{expr2}}' will evaluate
expr1 if elt1 and elt2 exist in pattern and elt3 doesn't exist, and
expr2 otherwise. The '{expr2}' part is optional.
The filtering, '%{+elt1,elt2,elt3{subexpr}}' will evaluate subexpr
with a pattern only having the listed elements from the surrounding
pattern.
The deletion, '%{-elt1,elt2,elt3{subexpr}}' will evaluate subexpr
with a the surrounding pattern sans the listed elements.
Diego Santa Cruz pointed out that we are using that API wrongly.
The forth argument is a pointer to a pointer. Turns out we don't
need that arugment and it accepts NULL, so just pass that.
Hinting will be done before Embolden in freetype2,
but in such case, Embolden will get wrong result
on some glyph contours after applying hinting.
Actually, hinting should be done after embolden, but we can't
fix it in current freetype2. So as a workaround, just turn off
hinting if we want to do embolden.
For Iraq, we are assuming its the same Arabic orthography used in Iran.
According to Ethnologue, Kurdish is written in Cyrillic in Armenia:
http://www.ethnologue.com/show_language.asp?code=kmr
Turkey and Syria need more research.
The previous version used the Devanagari script. But in both Pakistan and
India, Sindhi is generally written in Arabic. The Devanagari data could
prove to be useful, if we decide on how we should name such files (see
bug #17208 and bug #19869).
To only work on writable charsets. Also, return a bool indicating whether
the merge changed the charset.
Also changes the implementation of FcCharSetMerge and FcCharSetIsSubset
configure replaces a NONE prefix with the default prefix too late.
So we move fonts.conf creation to Makefile, such that prefix is correctly
expanded. Ugly, but works.
Previously an index j was added to element score to prefer matches earlier
in the value list to the later ones. This index started from 0, meaning
that the score zero could be generated for the first element. By starting
j from one, scores for when the element exists in both pattern and font
can never be zero. The score zero is reserved for when the element is
NOT available in both font and pattern. We will use this property later.
This shouldn't change matching much. The only difference I can think of
is that if a font family exists both as a bitmap font and a scalable
version, and when requesting it at the size of the bitmap version,
previously the font returned was nondeterministic. Now the scalable
version will always be preferred.
Previously the matcher multiplied comparison results by 100 and added
index value to it. With long lists of families (lots of aliases),
reaching 100 is not that hard. That could result in a non-match early
in the list to be preferred over a match late in the list. Changing
the multiplier from 100 to 1000 should fix that.
To keep things relatively in order, the lang multiplier is changed
from 1000 to 10000.
Previously fc-match "xxx,nazli" matched Nazli, but "xxx, nazli" didn't.
This was because of a bug in FcCompareFamily's short-circuit check
that forgot to ignore spaces.
Behdad Esfahbod
Mike FABIAN
Roozbeh Pournader
Karl Tomlinson
Dan Nicholson