Commit Graph

1886 Commits

Author SHA1 Message Date
Behdad Esfahbod cd4043da0d Check for non-empty outline for U+0000..U+001F
See comment for reason.
2017-09-12 17:02:27 -04:00
Behdad Esfahbod 028b91c781 Don't even check loca for glyph outline detection
Basically we trust the font cmap table now...

New numbers:

behdad:src 0$ time fc-scan ~/fonts/ > after-noloca

real	0m55.788s
user	0m15.836s
sys	0m17.008s
behdad:src 0$
behdad:src 0$ time fc-scan ~/fonts/ > after-noloca

real	0m24.794s
user	0m12.164s
sys	0m12.420s

Before this change it was:

behdad:src 130$ time fc-scan ~/fonts/ > after

real    0m24.825s
user    0m12.408s
sys     0m11.356s

Not any faster!  I suppose most time is being spent in loading cmap and advances now.
I'll see about loading hmtx ourselves.

With I/O numbers.  Before:

behdad:src 0$ \time fc-scan ~/fonts/ > after
11.66user 12.17system 0:24.03elapsed 99%CPU (0avgtext+0avgdata 487684maxresident)k
2320inputs+50480outputs (21major+11468549minor)pagefaults 0swaps

after:

behdad:src 130$ \time fc-scan ~/fonts/ > after-noloca
11.94user 11.99system 0:24.11elapsed 99%CPU (0avgtext+0avgdata 487704maxresident)k
16inputs+50688outputs (0major+11464386minor)pagefaults 0swaps

We are definitely doing a lot less I/O.  Surprisingly less in fact.  I don't get it.
2017-09-12 17:02:27 -04:00
Behdad Esfahbod ab02a49490 Instead of loading glyphs (with FreeType), just check loca table
Part of https://bugs.freedesktop.org/show_bug.cgi?id=64766#c47

This is the approach introduced in
https://bugs.freedesktop.org/show_bug.cgi?id=64766#c30

Testing it with 11GB worth of stuff, before/after:

behdad:src 130$ time fc-scan ~/fonts/ > before

real	2m18.428s
user	1m17.008s
sys	0m20.576s

behdad:src 0$ time fc-scan ~/fonts/ > after

real	1m12.130s
user	0m18.180s
sys	0m19.952s

Running the after case a second time is significantly faster:

behdad:src 130$ time fc-scan ~/fonts/ > after

real	0m24.825s
user	0m12.408s
sys	0m11.356s

Next I'm going to try to not even read loca...
2017-09-12 17:02:27 -04:00
Behdad Esfahbod 339de167c7 [fc-query] Fix linking order 2017-09-12 17:01:57 -04:00
Behdad Esfahbod b56207a069 Remove stray printf()
Ouch.
2017-09-12 17:01:25 -04:00
Behdad Esfahbod 6fb9b8fe49 Minor 2017-09-12 17:01:15 -04:00
Akira TAGOH 4d3410bd08 Bump version to 2.12.5 2017-09-09 22:34:36 +09:00
Akira TAGOH 37339b7b2c Update libtool versioning 2017-09-09 22:34:21 +09:00
Akira TAGOH 36a3ced949 Update docs 2017-09-09 22:17:16 +09:00
Akira TAGOH 92da67a9fc fc-blanks: fall back to the static data available in repo if downloaded data is corrupted
https://bugs.freedesktop.org/show_bug.cgi?id=102399
2017-08-25 11:47:09 +09:00
Akira TAGOH 12cf4c17db Update similar to emoji's 2017-08-23 13:39:15 +09:00
Akira TAGOH 69918f0eaa Polish und_zmth.orth more for Cambria Math and Minion Math 2017-08-23 12:36:15 +09:00
Akira TAGOH a7fcaed61e Polish und_zmth.orth for Libertinus Math 2017-08-23 11:21:10 +09:00
Akira TAGOH 53c4440ee3 Add und_zmth.orth to support Math in lang 2017-08-22 20:37:30 +09:00
Akira TAGOH ee609da358 Fix to work the debugging option on fc-validate 2017-08-22 20:30:34 +09:00
Akira TAGOH 5efa1137b4 Accept 4 digit script tag in FcLangNormalize(). 2017-08-22 17:58:22 +09:00
Akira TAGOH 651f122764 Do not ship fcobjshash.gperf in archive 2017-08-15 18:20:15 +09:00
Akira TAGOH dc56ff8040 Keep the same behavior to the return value of FcConfigParseAndLoad
reverting the behavior accidentally changed by 12b750

https://bugs.freedesktop.org/show_bug.cgi?id=102141
2017-08-13 16:18:46 +09:00
Behdad Esfahbod 41bc5eab84 Fix weight mapping
Ouch!
2017-08-08 15:34:57 -07:00
Behdad Esfahbod 8b29103196 Fix warning 2017-08-04 14:23:10 +01:00
Behdad Esfahbod 484cb300ea Fix sign-difference compare warning 2017-08-04 14:23:10 +01:00
Behdad Esfahbod 9bb36b42c9 Minor 2017-08-04 12:23:28 +01:00
Behdad Esfahbod 064440d597 Ignore 'und-' prefix for in FcLangCompare
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.
2017-08-03 11:17:35 +01:00
Behdad Esfahbod cc8442dec8 Adjust color emoji config some more
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.
2017-08-03 10:36:01 +01:00
Behdad Esfahbod 26fdd3e4c6 Remove unneeded codepoints 2017-08-02 16:48:33 +01:00
Akira TAGOH ef0b5f8901 Add more code points to und-zsye.orth 2017-08-02 16:02:41 +01:00
Behdad Esfahbod 7ef1723836 Minor 2017-08-02 15:41:26 +01:00
Behdad Esfahbod 9978203bf1 [fc-lang] Allow using ".." instead of "-" in ranges
Allows copying emoji-data.txt and other Unicode data files intact.
2017-08-02 15:31:15 +01:00
Akira TAGOH 1bb8e691bd Add und-zsye.orth to support emoji in lang 2017-08-02 15:18:53 +01:00
Behdad Esfahbod 2073477e05 Add EmojiOne Mozilla font 2017-08-02 13:34:01 +01:00
Behdad Esfahbod 368fe08f97 Add Twitter Color Emoji
https://bugs.freedesktop.org/show_bug.cgi?id=94551#c33
2017-08-02 13:04:36 +01:00
Behdad Esfahbod e5a51c8994 [fc-query] Support listing named instances 2017-08-01 14:41:02 +01:00
Behdad Esfahbod d7f3437ade Add generic family matching for "emoji" and "math"
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=94551
2017-07-31 17:17:16 +01:00
Behdad Esfahbod 241cc86932 Pass --pic to gperf 2017-07-31 15:56:06 +01:00
Akira TAGOH 5b6af242e1 Fix gcc warnings with enabling libxml2 2017-07-11 15:38:01 +09:00
Akira TAGOH db2825eed5 Bug 101726 - Sans config pulls in Microsoft Serifed font
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
2017-07-11 13:19:18 +09:00
Akira TAGOH 12b7501bad Add FcConfigParseAndLoadFromMemory() to load a configuration from memory.
https://bugs.freedesktop.org/show_bug.cgi?id=78452
2017-07-07 15:52:15 +09:00
Akira TAGOH ee2000494c Add FcPatternGetWithBinding() to obtain the binding type of the value in FcPattern.
https://bugs.freedesktop.org/show_bug.cgi?id=19375
2017-07-07 15:43:59 +09:00
Akira TAGOH 01085e0785 Bump version to 2.12.4 2017-07-05 17:37:26 +09:00
Akira TAGOH 047b42fcca Fix distcheck error 2017-07-05 17:35:28 +09:00
Akira TAGOH c35e8df46d Update libtool revision 2017-07-05 17:20:00 +09:00
Josselin Mouette e831f12a38 Treat C.UTF-8 and C.utf8 locales as built in the C library.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717423
https://bugs.freedesktop.org/show_bug.cgi?id=101605
2017-06-27 21:21:18 +09:00
Helmut Grohne 5d8ee5231a fix cross compilation
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
2017-06-27 18:49:20 +09:00
Florent Rougon 60e1fe550a FcCharSetFreezeOrig(), FcCharSetFindFrozen(): use all buckets of freezer->orig_hash_table
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.
2017-06-12 17:03:37 +09:00
Akira TAGOH 7940ada7a8 Add a testcase for Bug#131804 2017-06-12 13:36:56 +09:00
Florent Rougon b0a5b4b48e FcLangSetCompare(): fix bug when two charsets come from different "buckets"
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.
2017-06-12 13:36:22 +09:00
Florent Rougon 209619b1a6 Fix erroneous test on language id in FcLangSetPromote()
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".
2017-06-09 15:52:23 +09:00
Florent Rougon 4970c7e810 Fix an off-by-one error in FcLangSetIndex()
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.
2017-06-09 14:35:43 +09:00
Florent Rougon 02161ef2d6 fc-lang: gracefully handle the case where the last language initial is < 'z'
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.
2017-06-09 13:48:00 +09:00
Florent Rougon c37eeb8f1f FcCharSetHash(): use the 'numbers' values to compute the hash
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
cd2ec1a940 (June 2005).
2017-06-07 11:17:15 +09:00