just setting FC_MATCH=3 shows a lot of information and hard to keep on track for informamtion
which is really necessary to see. to use this more effectively, added FC_DBG_MATCH_FILTER to
see for what one really want to see. it takes a comma-separated-list of object names.
If you want to see family name only, try like this:
FC_DBG_MATCH_FILTER=family FC_DEBUG=4096 fc-match
debugging output will be filtered out and see family only in the result.
Continue to increase the object id even after FcFini()
and detect the overflow. that would be rather easier than
reset the object id with the complicated mutex and atomic
functions.
This situation would be quite unlikely to happen though
Adds FC_SYMBOL.
This affects fonts having a cmap with platform 3 encoding 0.
We now map their glyphs from the PUA area to the Latin1 area.
See thread "Webdings and other MS symbol fonts don't display"
on the mailing list.
Test before/after with:
$ pango-view --markup --text='<span fallback="false">×</span>' --font=Wingdings
Paths starting with '/' don't make sense on W32 as-is,
prepend the installation root directory to them.
This allows the cache to be contained within a particular
fontconfig installation (as long as the default
--with-cache-dir= is overriden at configure time).
Prior to the change of 32ac7c75e8
FcConfigAppFontAddFile() always returned FcTrue no matter what
fonts was added. after that, it always returned FcFalse because
adding a font doesn't add any subdirs with FcFileScanConfig().
so changing that to simply ignore it.
Also fixing it to return FcFalse if non-fonts was added, i.e.
FcFreeTypeQuery() fails.
https://bugs.freedesktop.org/show_bug.cgi?id=89617
After the change of d6a5cc665a
we have a lot of code points in FcBlanks. doing the linear search
on the array isn't comfortable anymore.
So re-implementing FcBlanksIsMember() to use the binary search.
Figuring out how much improved after this change depends on
how many fonts proceed with fc-cache say though, it's about 20 times
faster here on testing. which sounds good enough for
improvement.
Assuming that d_name is the last member of struct dirent.
In POSIX, the maximum length of d_name is defined as NAME_MAX
or FILENAME_MAX though, that assumption may be wrong on some
platforms where defines d_name as the flexible array member
and allocate the minimum memory to store d_name.
Patch from Raimund Steger