The format '%{family|delete( )}' expands to family values with space removed.
The format '%{family|translate( ,-)}' expands to family values with space
replaced by dash. Multiple chars are supported, like tr(1).
The format '%{family|escape(\\ )}' expands to family values with space
escaped using backslash.
The format '%{family|downcase}' for example prints the lowercase of
the family element. Three converters are defined right now:
'downcase', 'basename', and 'dirname'.
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.
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
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.
I can't understand why the special case is needed. Indeed, removing it
does not make any difference in the "fc-match --verbose" output, and
that's the only time fc-match uses FcPatternPrint.
Two changes:
- after mkdir(), we immediately chmod(), such that we are not affected
by stupid umask's.
- if a directory we want to use is not writable but exists, we try a
chmod on it. This is to recover from stupid umask's having affected
us with older versions.
The current behaviour of FcSortWalk() is to create a new FcCharSet on
each iteration that is the union of the previous iteration with the next
FcCharSet in the font set. This causes the existing FcCharSet to be
reproduced in its entirety and then allocates fresh leaves for the new
FcCharSet. In essence the number of allocations is quadratic wrt the
number of fonts required.
By introducing a new method for merging a new FcCharSet with an existing
one we can change the behaviour to be effectively linear with the number
of fonts - allocating no more leaves than necessary to cover all the
fonts in the set.
For example, profiling 'gedit UTF-8-demo.txt'
Allocator nAllocs nBytes
Before:
FcCharSetFindLeafCreate 62886 2012352
FcCharSetPutLeaf 9361 11441108
After:
FcCharSetFindLeafCreate 1940 62080
FcCharSetPutLeaf 281 190336
The savings are even more significant for applications like firefox-3.0b5
which need to switch between large number of fonts.
Before:
FcCharSetFindLeafCreate 4461192 142758144
FcCharSetPutLeaf 1124536 451574172
After:
FcCharSetFindLeafCreate 80359 2571488
FcCharSetPutLeaf 18940 9720522
Out of interest, the next most frequent allocations are
FcPatternObjectAddWithBinding 526029 10520580
tt_face_load_eblc 42103 2529892
Note that this also fixes a bug with FcFontList() where previously
it was NOT checking whether the config is up-to-date. May want to
keep the old behavior and document that ScanInterval is essentially
unused internally (FcFontSetList uses it, but we can remove that
too).
A private FcObjectGetSet() is implemented that provides an
FcObjectSet of all registered elements. FcFontSetList() is
then modified to use the object set from FcObjectGetSet() if
provided object-set is NULL.
Alternatively FcObjectGetSet() can be made public. In that
case fc-list can use that as a base if --verbose is included,
and also add any elements provided by the user (though that has
no effect, as all elements from the cache are already registered).
Currently fc-list ignores user-provided elements if --verbose
is specified.
The fact that we now drop final slashes from all filenames without
checking that the file name represents a directory may surprise some,
but it doesn't bother me really.
At OLPC, we came across a bug where the Browse activity (based on xulrunner)
took 100% CPU after an upgrade/. It turns out the Mozilla uses
FcConfigUptoDate() to check if new fonts have been added to the system, and
this function was always returning FcFalse since we have the mtimes of some
font directories set in the future. The attached patch makes
FcConfigUptoDate() print a warning and return FcTrue if mtime of directories
are in the future.
It seems indices in _FcMatchers array are slightly mixed up, MATCH_DECORATIVE
should be 10, not 11.
And MATCH_RASTERIZER_INDEX should be 13, not 12, right?
Libtool-2.2 introduces new restrictions. So now it does not allow LT_*
variables as it includes marcros:
m4_pattern_forbid([^_?LT_[A-Z_]+$])
Rename the LT_ variables to LIBT_ to work around this restriction.
Building 2.5.91 on Solaris with the native make(1) yields
...
Making all in src
make: Fatal error in reader: Makefile, line 313: Unexpected end of line seen
Current working directory /tmp/fontconfig-2.5.91/src
*** Error code 1
This is due to the following line (src/Makefile.am:143):
CLEANFILES := $(ALIAS_FILES)
Changing that to a standard assignment ("=") fixes the problem.
I believe the ":=" is a typo. ALIAS_FILES is just a statically assigned
variable; it's not like evaluating it more than once would be a problem.
If the /usr/bin/head program is missing or unusable, or if an unusable head
program is listed first in the PATH, fontconfig fails to build
using "sed -n 1p" instead of "head -1" would be a suitable workaround.
Since fontconfig didn't have special handling for paths in static Windows
libraries, I've created a patch which should fix this.
Basically it does this:
fccfg.c:
If fontconfig_path was uninitialised it tries to get the directory the exe is
in and uses a fonts/ dir inside that.
fcxml.c:
In case the fonts.conf lists a <dir>CUSTOMFONTDIR</dir>, it searches for a
fonts/ directory where the exe is located.
David Turner has modified FreeType to be able to render sub-pixel decimated
glyphs using different methods of filtering. Fontconfig needs new
configurables to support selecting these new filtering options. A patch
follows that would correspond to one available for Cairo in bug 10301.
Bitmap-only TrueType fonts without a glyf table will not load a glyph when
FT_LOAD_NO_SCALE is set. Work around this by identifying TrueType fonts that have no
glyphs and select a single strike to measure the glyph map with.
For Version 2.5.0, (same for previous version 2.4.2), in source file fccfg.c,
on line 700,
Original:
ret = FcStrCmpIgnoreCase (left.u.s, right.u.s) == 0;
Should change to:
ret = FcStrStrIgnoreCase (left.u.s, right.u.s) == 0;
I think this is just a mistake when copy-n-paste similar codes in the same
function. Apparently, return for "Not_contain" should be just the inverse of
"Contain", not the same as "Equal".
Fix a couple of longstanding problems with fontconfig on Windows that
manifest themselves especially in GIMP. The root cause to the problems is in
Microsoft's incredibly stupid stat() implementation. Basically, stat()
returns wrong timestamp fields for files on NTFS filesystems on machines
that use automatic DST switching.
See for instance http://bugzilla.gnome.org/show_bug.cgi?id=154968 and
http://www.codeproject.com/datetime/dstbugs.asp
As fccache.c now looks at more fields in the stat struct I fill in them all.
I noticed that fstat() is used only on a fd just after opening it, so on
Win32 I just call my stat() replacement before opening instead...
Implementing a good replacement for fstat() would be harder because the code
in fccache.c wants to compare inode numbers. There are no (readily
accessible) inode numbers on Win32, so I fake it with the hash of the full
file name, in the case as it is on disk. And fstat() doesn't know the full
file name, so it would be rather hard to come up with a inode number to
identify the file.
The patch also adds similar handling for the cache directory as for the fonts
directory: If a cachedir element in fonts.conf contains the magic string
"WINDOWSTEMPDIR_FONTCONFIG_CACHE" it is replaced at runtime with a path under
the machine's (or user's) temp folder as returned by GetTempPath(). I don't
want to hardcode any pathnames in a fonts.conf intended to be distributed to
end-users, most of which who wouldn't know how to edit it anyway. And
requiring an installer to edit it gets complicated.
This reverts commit b607922909.
Conflicts:
src/Makefile.am
Xft still uses the macros that are in fcprivate.h. Document those macros and
include fcprivate.h in the published header files.
These two names are typos of the correct names. Instead of simply changing
them, the correct thing to do is leave them in the library, add the correct
functions and mark them as deprecated so any source packages will be updated.
This requires bumping the minor version of the library (for adding APIs)
instead of bumping the major version of the library (for removing APIs).
fcprivate.h was supposed to extend the fontconfig API for the various
fontconfig utilities. Instead, just have those utilities use the internal
fcint.h header file (which they already do), removing fcprivate.h from the
installation and hence from the defacto public API.
If the provided style value doesn't match any available font, fall back to
using the weight and slant values by ensuring that those are in the pattern.
Glyph names (now used only for dingbats) were using many relocations,
causing startup latency plus per-process memory usage. Replace pointers with
table indices, shrinking table size and elimninating relocations.
The cache was inserted into the hash table before the timestamps in the
cache were verified; if that verification failed, an extra pointer to the
now freed cache would be left in the hash table. FcFini would fail an
assertion as a result.
If ~/.fonts.conf contains:
<edit mode="assign_replace" name="spacing">
<int>mono</int>
</edit>
fontconfig crashes:
mfabian@magellan:~$ fc-match sans
Fontconfig error: "~/.fonts.conf", line 46: "mono": not a valid
integer
セグメンテーション違反です (core dumped)
mfabian@magellan:~$
Of course the above is nonsense, “mono” is no valid integer indeed.
But I think nevertheless fontconfig should not crash in that case.
The problem was caused by partially truncated expression trees caused by
parse errors -- typechecking these walked the tree without verifying the
integrity of the structure. Of course, the whole tree will be discarded
shortly after being loaded as it contained an error.
Some mingw versions have broken X_OK checking; instead of trying to work
around this in a system-depedent manner, simply don't bother checking for
X_OK along with W_OK as such cases are expected to be mistakes, and not
sensible access control.
The old policy of eliding fullname entries which matched FC_FAMILY or
FC_FAMILY + FC_STYLE meant that applications could not know what the
font foundry set as the fullname of the font. Hiding information is not
helpful.
Instead of relying on mtime ordering between a directory and its associated
cache file, write the directory mtime into the cache file itself. This makes
cache file checks more reliable across file systems.
This change is made in a way that old programs can use new cache files, but
new programs will need new cache files.
In FcDirCacheUnlink(), the line
cache_hashed = FcStrPlus (cache_dir, cache_base);
allocates memory in cache_hashed that is never free()'d before the function
exits.
Reported by Ben Combee.
Recent versions of FreeType do not correctly deal with glyph name buffers
that are too small; work around this by declaring a buffer that can hold any
PS name (127 bytes).
I noticed that Qt always uses a different font than fc-match advertises.
Debugging the issue, I found that a call that looks pretty innocent is
changing all weak bindings to strong bindings and as such changes the
semantic of the match: FcPatternDuplicate.
Missing NULL font check before attempting to edit scanned pattern.
Also, <match target="scan"> rules are now checked to ensure all
edited variables are in the predefined set; otherwise, the resulting
cache files will not be stable.
Behdad Esfahbod
Karl Tomlinson
Harald Fernengel
Chris Wilson
Keith Packard
Sayamindu Dasgupta
Evgeniy Stepanov
Carlo Bramini
Ryan Schmidt
Dennis Schridde
Sylvain Pasche
Hongbo Zhao
Tor Lillqvist
Keith Packard
Behdad Esfahbod
Keith Packard
Tilman Sauerbeck
Mike FABIAN
Stephan Kulow