The syntax to add any characters to the charset table looks like:
<match target="scan">
<test name="family">
<string>Buggy Sans</string>
</test>
<edit name="charset" mode="assign">
<plus>
<name>charset</name>
<charset>
<int>0x3220</int> <!-- PARENTHESIZED IDEOGRAPH ONE -->
</charset>
</plus>
</edit>
</match>
To remove any characters from the charset table:
<match target="scan">
<test name="family">
<string>Buggy Sans</string>
</test>
<edit name="charset" mode="assign">
<minus>
<name>charset</name>
<charset>
<int>0x06CC</int> <!-- ARABIC LETTER FARSI YEH -->
<int>0x06D2</int> <!-- ARABIC LETTER YEH BARREE -->
<int>0x06D3</int> <!-- ARABIC LETTER YEH BARREE WITH HAMZA ABOVE -->
</charset>
</minus>
</edit>
</match>
You could also use the range element for convenience:
...
<charset>
<int>0x06CC</int> <!-- ARABIC LETTER FARSI YEH -->
<range>
<int>0x06D2</int> <!-- ARABIC LETTER YEH BARREE -->
<int>0x06D3</int> <!-- ARABIC LETTER YEH BARREE WITH HAMZA ABOVE -->
</range>
</charset>
...
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.
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.
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".
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).
With the cache restructuring of 2.4.0, the ability to add
application-specific font files and directories was accidentally lost.
Reimplement this using by sharing the logic used to load configured font
directories.
Using a simple shell script that processes the public headers, two header
files are constructed that map public symbols to hidden internal aliases
avoiding the assocated PLT entry for referring to a public symbol.
A few mistakes in the FcPrivate/FcPublic annotations were also discovered
through this process
Eliminate need to reference cache object once per cached font, instead
just count the number of fonts used from the cache and bump the reference
count once by that amount. I think this makes this refernece technique
efficient enough for use.
Caches contain patterns and character sets which are reference counted and
visible to applications. Reference count the underlying cache object so that
it stays around until all reference objects are no longer in use.
This is less efficient than just leaving all caches around forever, but does
avoid eternal size increases in case applications ever bother to actually
look for changes in the font configuration.
The Delicious family includes one named Delicious Heavy, a bold variant
which is unfortunately marked as having normal weight. Because the family
name is 'Delicious', fontconfig accidentally selects this font instead of
the normal weight variant. The fix here rewrites the scanned data by running
the scanned pattern through a new substitution sequence tagged with
<match target=scan>; a sample for the Delicious family is included to
demonstrate how it works (and fix Delicious at the same time).
Also added was a new match predicate -- the 'decorative' predicate which is
automatically detected in fonts by searching style names for key decorative
phrases like SmallCaps, Shadow, Embosed and Antiqua. Suggestions for
additional decorative key words are welcome. This should have little effect
on font matching except when two fonts share the same characteristics except
for this value.
Instead of passing directory information around in separate variables,
collect it all in an FcCache structure. Numerous internal and tool
interfaces changed as a result of this.
Charsets are now pre-frozen before being serialized. This causes them to
share across multiple fonts in the same cache.
Validate cache contents and skip broken caches, looking down cache path for
valid ones.
Every time a directory is scanned, it will be written to a cache file if
possible, so fc-cache doesn't need to re-write the cache file. This makes
detecting when the cache was generated a bit tricky, so we guess that if the
cache wasn't valid before running and is valid afterwards, the cache file
was written.
Also, allow empty charsets to be serialized with null leaves/numbers.
Eliminate a leak in FcEdit by switching to FcObject sooner.
Call FcFini from fc-match to make valgrind happy.
Replace all of the bank/id pairs with simple offsets, recode several
data structures to always use offsets inside the library to avoid
conditional paths. Exposed data structures use pointers to hold offsets,
setting the low bit to distinguish between offset and pointer.
Use offset-based data structures for lang charset encodings; eliminates
separate data structure format for that file.
Much testing will be needed; offsets are likely not detected everywhere in
the library yet.
With the removal of the in-directory cache files, and the addition of
per-user cache directories, there is no longer any reason to preserve the
giant global cache file. Eliminating of this unifies the cache structure
and simplifies the overall caching strategies greatly.
Normalized directory names offer protection against looped directory trees
but cost enormous numbers of system calls (stat per file in the hierarchy).
Also, cache file directory name contents are validated each time the
directory is modified, don't re-validate every time the cache file is loaded
with an access and stat call.
Check if pattern is not null before using it (Coverity defect #1883).
Fix memory leak with hash collision (Coverity defect #1829).
Fix memory leak when bail cases (Coverity defect #1828).
Don't leak directory name (Coverity defect #1827).
reviewed by: plam