Reject caches when FcPattern isn't a constant.
This is usually unlikely to happen but reported.
I've decided to add more validation since this isn't reproducible
and easy to have a workaround rather than investigating 'why'.
https://bugs.freedesktop.org/show_bug.cgi?id=103237
Trying to address what these configuration files really do.
This change allows to see the short description that mention
the purpose of the content in the config file and obtain
them through API.
This change also encourage one who want to make some UI for
the user-specific configuration management. it is the main
purpose of this change for me though.
Aside from that, I've also made programs translatable. so
we see more dependencies on the build time for gettext,
and itstool to generate PO from xml.
VotoSerifGX has over 500 named instances, which means it also has over a thousand
name table entries. So we were looking for names for over 500 pattern, looking for
some thirty different name-ids, and using linear search across the 1000 entries!
Makes scanning VotoSerifGX three times faster. The rest is probably the lang
matching, which can also be shared across named-instances. Upcoming.
This reverts commit 57764e3a36449da25bb829c34cb08c54e9e5de90.
For regular font pattern we don't look into fvar, so it doesn't make sense to
get non-variation from it either.
Has two distinctions from FcCompareRange():
1. As best value, it returns query pattern size, even if it's out of font range,
2. Implements semi-closed interval, as that's what OS/2 v5 table defines
If font claims to support range [100,900], and request is for [250], then
return [250] in "rendered" pattern. Previously was returning [100,900].
This is desirable for varfonts weight and width, but probably not for size.
Will roll back size to return request size always, for non-empty ranges.
If "instance-number" part of face id is set to 0x8000, return a pattern
for variable font as a whole. This might have a range for weight, width,
and size.
If no variation is found, NULL is returned.
Not hooked up to FcQueryFaceAll() yet. For now, can be triggered using
fc-query -i 0x80000000
There's nothing assymetrical about how we match them. Previously we "considered"
them half-open because the OS/2 spec had usLowerOpticalPointSize as inclusive
and usUpperOpticalPointSize as exclusive. But we do not respect that.
Note that the parsing code accepts both anyway, because of the way our sscanf()
usage is written...
This is for clients to passthru font variation settings. Modeled
similar to FC_FONT_FEATURES. Each element value is for one axis
settings, eg. "abcd=2.3" where 'abcd' is the OpenType Font Variations
axis tag.
Needs docs update.
Use FcCompareNumber(). The FcCompareSize() returns 0 ("perfect match")
if v2 is zero. I cannot think of a use-case for this. The code has been
there from initial commit in 2002. I suppose back then Keith had a use
for size=0 to mean scalable or something. Anyway, remove and see.
Like FcFreeTypeQuery(), but adds patterns for all fonts found, including named
instances of variable fonts. If id is -1, then all collection faces are queried.
Returns number of fonts added.
This merges the same face loop that was in fc-query. and fcdir.c.
Needs documentation update.
Ignore control chars for purpose of emptiness check. I *think* U+0000 and U+000D
are rendered empty, but since they are not in blanks, for now just ignore them.
The FT_Select_Size() call is important for bitmap-only fonts.
Put it back. It was removed in e327c4e54544dac5415e8864e80d6b75a0c900fd
Remove some unused abstractions.
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.
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...
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.
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.
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".
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.
Akira TAGOH
Alexander Kanavin
Behdad Esfahbod
Josselin Mouette
Florent Rougon