- 13 Aug, 2017 1 commit
-
-
Akira TAGOH authored
reverting the behavior accidentally changed by 12b750 https://bugs.freedesktop.org/show_bug.cgi?id=102141
-
- 08 Aug, 2017 1 commit
-
-
Behdad Esfahbod authored
Ouch!
-
- 04 Aug, 2017 3 commits
-
-
Behdad Esfahbod authored
-
Behdad Esfahbod authored
-
Behdad Esfahbod authored
-
- 03 Aug, 2017 2 commits
-
-
Behdad Esfahbod authored
See https://bugs.freedesktop.org/show_bug.cgi?id=94551#c54 For example, matching for :lang=und-zsye matches emoji font, but searching for :lang=und-xyz wouldn't match an emoji font anymore. Neither does :lang-und.
-
Behdad Esfahbod authored
Seems to work now. Either asking for family emoji, or :lang=und-zsye returns the preferred color emoji font available, or just any color emoji font if none of the preferred ones was found.
-
- 02 Aug, 2017 7 commits
-
-
Behdad Esfahbod authored
-
Akira TAGOH authored
-
Behdad Esfahbod authored
-
Behdad Esfahbod authored
Allows copying emoji-data.txt and other Unicode data files intact.
-
Akira TAGOH authored
-
Behdad Esfahbod authored
-
-
- 01 Aug, 2017 1 commit
-
-
Behdad Esfahbod authored
-
- 31 Jul, 2017 2 commits
-
-
-
Behdad Esfahbod authored
-
- 11 Jul, 2017 2 commits
-
-
Akira TAGOH authored
-
Akira TAGOH authored
Update 65-nonlatin.conf to have better choice of the sans-serif fonts for Chinese Patch from Joseph Wang https://bugs.freedesktop.org/show_bug.cgi?id=101726
-
- 07 Jul, 2017 2 commits
-
-
- 05 Jul, 2017 3 commits
-
-
Akira TAGOH authored
-
Akira TAGOH authored
-
Akira TAGOH authored
-
- 27 Jun, 2017 2 commits
-
-
Helmut Grohne authored
Even though fontconfig's build system tries to build edit-sgml with the build arch compiler, it gets the runes wrong and actually builds it with the host arch compiler. This patch makes it use the right compiler. Bug-Debian: https://bugs.debian.org/779461 https://bugs.freedesktop.org/show_bug.cgi?id=101554
- 12 Jun, 2017 3 commits
-
-
Florent Rougon authored
As written at: https://lists.freedesktop.org/archives/fontconfig/2017-June/005929.html I think FcCharSetFreezeOrig() and FcCharSetFindFrozen() should use the % operator instead of & when computing the bucket index for freezer->orig_hash_table, otherwise at most 8 buckets among the 67 available (FC_CHAR_SET_HASH_SIZE) are used. Another way would be to change FC_CHAR_SET_HASH_SIZE to be of the form 2**n -1 (i.e., a power of two minus one). In such a case, the & and % operators would be equivalent.
-
Akira TAGOH authored
-
Florent Rougon authored
In fcLangCountrySets, it may happen that two charsets for the same language but different territories are found in different FcChar32 "buckets" (different "columns" on the same line). This is currently the case for the following pairs: mn-cn and mn-mn pap-an and pap-aw The FcLangSetCompare() code so far used to return FcLangDifferentLang instead of FcLangDifferentTerritory when comparing: an FcLangSet containing only mn-cn with one containing only mn-mn or an FcLangSet containing only pap-an with one containing only pap-aw This commit fixes this problem.
-
- 09 Jun, 2017 3 commits
-
-
Florent Rougon authored
FcLangSetIndex() indicates "not found" with a non-negative return value. Return value 0 doesn't imply "not found", it rather means "language found at index 0 in fcLangCharSets".
-
Florent Rougon authored
This commit fixes a bug that can be reproduced like this: - remove all languages starting with 'a' in fc-lang/Makefile.am (in ORTH's definition); - rebuild fontconfig with this change (-> new fc-lang/fclang.h); - create an FcLangSet 'ls1' that contains at least the first language from fcLangCharSets (i.e., the first *remaining* in lexicographic order); let's assume it is "ba" for the sake of this description; - create an FcLangSet 'ls2' that only contains the language "aa" (any language starting with 'a' should work as well); - check the return value of FcLangSetContains(ls1, ls2); The expected return value is FcFalse, however it is FcTrue if you use the code before this commit. What happens is that FcLangSetIndex() returns 0, because this is the index of the first slot after the not-found language "aa" in fcLangCharSets (since we removed all languages starting with 'a'). However, this index happens to be non-negative, therefore FcLangSetContainsLang() mistakenly infers that the language "aa" was found in fcLangCharSets, and thus calls FcLangSetBitGet(ls1, 0), which returns FcTrue since we've put the first remaining language "ba" in the 'ls1' language set. The "return -low;" statement previously in FcLangSetIndex() was inconsistent with the final return statement. "return -(low+1);" fixes this inconsistency as well as the incorrect behavior described above.
-
Florent Rougon authored
FcLangSetIndex() contains code like this: low = fcLangCharSetRanges[firstChar - 'a'].begin; high = fcLangCharSetRanges[firstChar - 'a'].end; /* no matches */ if (low > high) The assumption behind this test didn't hold before this commit, unless there is at least one language name that starts with 'z' (which is thankfully the case in our world :-). If the last language name in lexicographic order starts for instance with 'x', this change ensures that fcLangCharSetRanges['y' - 'a'].begin and fcLangCharSetRanges['z' - 'a'].begin are equal to NUM_LANG_CHAR_SET, in order to make the above assumption correct in all cases.
-
- 07 Jun, 2017 1 commit
-
-
Florent Rougon authored
Before this commit, FcCharSetHash() repeatedly used the address of the 'numbers' array of an FcCharSet to compute the FcCharSet hash, instead of the value of each array element. This is not good for even spreading of the FcCharSet objects among the various buckets of the hash table (and should thus reduce performance). This bug appears to have been mistakenly introduced in commit cd2ec1a9 (June 2005).
-
- 05 Jun, 2017 1 commit
-
-
Akira TAGOH authored
-
- 03 Jun, 2017 1 commit
-
-
Akira TAGOH authored
To avoid a situation of mismatching the declaration of hash function
-
- 01 Jun, 2017 2 commits
-
-
Masamichi Hosoda authored
On Windows, opened or locked files cannot be removed. Since fontconfig locked an old cache file while updating the file, fontconfig failed to replace the file with updated file on Windows. This patch makes fontconfig does not lock the old cache file while updating it on Windows.
-
Jan Alexander Steffens authored
-
- 31 May, 2017 3 commits
-
-
Akira TAGOH authored
-
Akira TAGOH authored
-
Akira TAGOH authored
-