Add an ability to set the system root to generate the caches.
In order to do this, new APIs, FcConfigGetSysRoot() and
FcConfigSetSysRoot() is available.
Maps fonts produced by the Culmus project <http://culmus.sourceforge.net>
to the XLFD foundry name culmus.
For TrueType fonts, maps the vendor code CLM from the TrueType vendor id field.
For Type1 fonts, which use heuristics to guess mappings to XLFD foundries from
words in the copyright notice, add the names of the main contributors to
the Culmus product to recognize the fonts under their copyright.
Patch from Maxim Iorsh
Add two edit mode, "delete" and "delete_all".
what values are being deleted depends on <test> as documented.
if the target object is same to what is tested, matching value there
will be deleted. otherwise all of values in the object will be deleted.
so this would means both edit mode will not take any expressions.
e.g.
Given that the testing is always true here, the following rules:
<match>
<test name="foo" compare="eq">
<string>bar</string>
</test>
<edit name="foo" mode="delete"/>
</match>
will removes "bar" string from "foo" object. and:
<match>
<test name="foo" compare="eq">
<string>foo</string>
</test>
<edit name="bar" mode="delete"/>
</match>
will removes all of values in "bar" object.
This changes allows to have multiple mathcing rules in one <match> block
in the same order.
After this changes, the following thing will works as two matching rules:
<match>
<!-- rule 1 -->
<test name="family" compare="eq">
<string>foo</string>
</test>
<edit name="foo" mode="append">
<string>foo</string>
</edit>
<!-- rule 2 -->
<test name="foo" compare="eq">
<string>foo</string>
</test>
<edit name="foo" mode="append">
<string>bar</string>
</edit>
</match>
In FcStrListCreate() we were increasing reference count of set,
however, if set had a const reference (which is the case for list
of languages), and with multiple threads, the const ref (-1) was
getting up to 1 and then a decrease was destroying the set. Ouch.
Here's the valgrind error, which took me quite a few hours of
running to catch:
==4464== Invalid read of size 4
==4464== at 0x4E58FF3: FcStrListNext (fcstr.c:1256)
==4464== by 0x4E3F11D: FcConfigSubstituteWithPat (fccfg.c:1508)
==4464== by 0x4E3F8F4: FcConfigSubstitute (fccfg.c:1729)
==4464== by 0x4009FA: test_match (simple-pthread-test.c:53)
==4464== by 0x400A6E: run_test_in_thread (simple-pthread-test.c:68)
==4464== by 0x507EE99: start_thread (pthread_create.c:308)
==4464== Address 0x6bc0b44 is 4 bytes inside a block of size 24 free'd
==4464== at 0x4C2A82E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4464== by 0x4E58F84: FcStrSetDestroy (fcstr.c:1236)
==4464== by 0x4E3F0C6: FcConfigSubstituteWithPat (fccfg.c:1507)
==4464== by 0x4E3F8F4: FcConfigSubstitute (fccfg.c:1729)
==4464== by 0x4009FA: test_match (simple-pthread-test.c:53)
==4464== by 0x400A6E: run_test_in_thread (simple-pthread-test.c:68)
==4464== by 0x507EE99: start_thread (pthread_create.c:308)
Thread test is running happily now. Will add the test in a moment.
We used to have a shared-str pool. Removed to make thread-safety
work easier. My measurements show that the extra overhead is not
significant by any means.
These never worked as intended. The problem is, if Fontconfig tries to
read config files when these new types / constants are not registered,
it errs. As a result, no defined types / constants are usable from
config files. Which makes these really useless. Xft was the only user
of this API and even there it's not really used. Just kill it.
One inch closer to thread-safety since we can fix the object-type hash
table at compile time.
The type will be resolved at runtime...
For example, we can do this now without getting a warning:
<match target="font">
<test name="scalable" compare="eq">
<bool>false</bool>
</test>
<edit name="pixelsizefixupfactor" mode="assign">
<divide>
<name target="pattern">pixelsize</name>
<name target="font" >pixelsize</name>
</divide>
</edit>
<edit name="matrix" mode="assign">
<times>
<name>matrix</name>
<matrix>
<name>pixelsizefixupfactor</name> <double>0</double>
<double>0</double> <name>pixelsizefixupfactor</name>
</matrix>
</times>
</edit>
<edit name="size" mode="assign">
<divide>
<name>size</name>
<name>pixelsizefixupfactor</name>
</divide>
</edit>
</match>
Previously the last edit was generating:
Fontconfig warning: "/home/behdad/.local/etc/fonts/conf.d/00-scale-bitmap-fonts.conf", line 29: saw unknown, expected number
Based on idea from Raimund Steger.
For example, one can do something like this:
<match target="font">
<test name="scalable" compare="eq">
<bool>false</bool>
</test>
<edit name="pixelsizefixupfactor" mode="assign">
<divide>
<name target="pattern">pixelsize</name>
<name target="font" >pixelsize</name>
</divide>
</edit>
<edit name="matrix" mode="assign">
<times>
<name>matrix</name>
<matrix>
<name>pixelsizefixupfactor</name> <double>0</double>
<double>0</double> <name>pixelsizefixupfactor</name>
</matrix>
</times>
</edit>
</match>
Part of work to make bitmap font scaling possible. See thread
discussion:
http://lists.freedesktop.org/archives/fontconfig/2012-December/004498.html
Previously a <matrix> element could only accept four <double> literals.
It now accepts full expressions, which can in turn poke into the
pattern, do math, etc.
After 7587d1c99d applied, family,
style, and fullname is localized against current locale or lang
if any though, the string in other languages were dropped from
the pattern. this caused unexpected mismatch on the target="font"
rules.
This fix adds other strings at the end of the list.
X_OK checking was added back in 8ae1e3d5dc
which was removed due to the same reason in
238489030a.
apparently the test case in Bug#18934 still works without it.
so I'm removing it again to get this working on Windows.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 8: reading configurations from ~/.fonts.conf.d is deprecated.
Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated.
Be polite and do not issue the warning if deprecated config includes
(e.g. ~/.fonts.conf.d and/or ~/.fonts.conf) do not exist.
Windows does not update mtime of directory on FAT filesystem when
file is added to it or removed from it. Fontconfig uses mtime of
directory to check cache file aging and hence fails to detect
newly added or recently removed files.
This changeset detects FAT filesystem (currently implemented for
Linux) and adds generating checksum of directory entries instead
of using mtime which guarantees proper cache rebuild.
For non-FAT filesystems this patch adds single syscall per directory
which is negligeable overhead.
This fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=25535
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
FcStat() logic is quite complicated in presence of various semi-broken operating
systems and filesystems, split it out in order to make it a bit easier.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
link(2) might be failed on the filesystem that doesn't support
the hard link. e.g. FcAtomicLock() always fails on FAT filesystem
when link(2) is available.
So that may be a good idea to fallback if link(2) is failed.
Warn if the multiple values is set to <test>, including the case of
in <alias> because the behavior isn't intuitive since so many users
is asking for a help to get things working for their expectation.
Use multiple <match>s or <alias>es for OR operator and
multiple <test>s for AND operator.
Allows reading configuration files, fonts and cache files from
the directories where the XDG Base Directory Specification defines.
the old directories are still in the configuration files for
the backward compatibility.
Add a new attribute `ignore-blanks' to <test>.
When this is set to "true", any blanks in the string will be ignored
on comparison. This takes effects for compare="eq" or "not_eq" only.
Also changed the behavior of the comparison on <alias> too.
This patch isn't really tested as I don't have such a machine, but I
have a bug report that on m68k machines, double values are aligned on
smaller than 4 byte boundaries. If ALIGNOF_DOUBLE < sizeof(int),
the "expected" sizeof of FcValue is miscomputed. Use the maximum of 4
(sizeof (int)) and ALIGNOF_DOUBLE when computing the expected size of
FcValue.
Signed-off-by: Keith Packard <keithp@keithp.com>
Stop using mmap() if the cache file is stored on NFS.
also added FONTCONFIG_USE_MMAP environment variable to enforce the use of
or not the use of mmap(2) regardless of what the filesystem the cache files
are stored on.
Add "namelang" object to obtain the localized name in the font regardless
of the lang object. it's applied to "familylang", "stylelang" and
"fullnamelang" alltogether. this would helps if one wants to enforce
selecting them in the specific language if any. the default value for
the namelang object is determined from current locale.
Given that fontconfig will scan all of the cache file data during the
first font search, ask the kernel to start reading the pages right away.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add configure options to set the directory to be installed:
--with-templatedir for the configuration files a.k.a.
/etc/fonts/conf.avail
--with-baseconfigdir for fonts.conf etc a.k.a. /etc/fonts
--with-configdir for the active configuration files a.k.a.
/etc/fonts/conf.d
--with-xmldir for fonts.dtd etc
and the default path for templatedir is changed to
${datadir}/fontconfig/conf.avail
This is a reasonably conservative increase in the number of buckets in the hash
table to 251. After FcInit(), there are 240 shared strings in use on my system
(from configuration files I assume). The hash value is stored in each link in
the chains so comparison are actually not very expensive. This change should
reduce the average length of chains by a factor of 8. With the reference
counted strings, it should keep the average length of chains to about 2. The
number of buckets is prime so as not to rely too much on the quality of the
hash function.
https://bugs.freedesktop.org/show_bug.cgi?id=17832#c5
Patch from Karl Tomlinson
In the previous code, the result of 'result' in the argument for
FcFontSetSort() and FcFontSetMatch() wasn't predictable and not reliable to
check if the return value is valid or not. this change is to ensure if it's
performed successfully.
$< isn't supported in BSD make say. $(RM) is pre-defined in GNU make
though, not in BSD make say. so changed to check on configure if it's
pre-defined by make, otherwise set the appropriate command to $(RM).
This would be a workaround until it has the certain pre-defined value.
When adding new functions, if the actual definition doesn't match the
header (say due to a typo), the regeneration of the internal headers
get confused and output bad cpp logic. This causes gcc to barf due
to mismatched #ifdef/#endif. Which is a pain to figure out due to
the sheer voulme of generated code.
So tweak the makealias script to detect this case and error out.
While we're here, improve the cpp output a bit to indent, include
comments, and merge similar ifdef blocks.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Newer gcc doesn't like when you switch on an enum and use a value
that isn't declared:
fcname.c: In function 'FcObjectValidType':
fcname.c:299:2: warning: case value '4294967295'
not in enumerated type 'FcType' [-Wswitch]
So tweak the logic to avoid this warning.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Latest configure code will setup FC_ARCHITECTURE directly rather than
going through ARCHITECTURE, so update fcarch.h accordingly.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
These funcs don't modify the incoming string, so add const markings.
This is the "right thing", shouldn't change the ABI, and fixes some
gcc warnings:
fccfg.c: In function 'FcConfigEvaluate':
fccfg.c:916:2: warning: passing argument 1 of 'IA__FcNameConstant'
discards 'const' qualifier from pointer target type [enabled by default]
fcalias.h:253:34: note: expected 'FcChar8 *' but
argument is of type 'const FcChar8 *'
fcxml.c: In function 'FcTypecheckExpr':
fcxml.c:604:2: warning: passing argument 1 of 'IA__FcNameGetConstant'
discards 'const' qualifier from pointer target type [enabled by default]
fcalias.h:251:37: note: expected 'FcChar8 *' but
argument is of type 'const FcChar8 *'
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This shouldn't affect the ABI, makes FcStat more like the rest of the
fontconfig API, and fixes warnings where we pass FcChar8* pointers in
to this func from other places.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We've already calculated the lengths of these strings, so re-use those
values to avoid having to rescan the strings multiple times.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
I broke FcFontSort() language handling at the end of 2008 with this
commit: c7641f28
G-d knows how many of the lang-matching bugs in bugzilla will be
fixed by this changed...
I'm really sorry, everyone!
- Do not throw away FC_FILE in FcNameUnparse
- Update the builtin "fclist" format to remove FC_FILE properly instead
- Switch fc-list to use FcPatternFormat()
Note that I had previously broken fc-list and it was not showing the
file name anymore. No one noticed that it seems! Now fixed.
Do not remove blacklisted fonts during cache generation. We already
apply the blacklist when reading the caches. The idea always has been
that the config should not affect caches built, although that design
was tarnished with the introduction of target="scan" configurations.
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>
...
The OT spec says:
"When building a Unicode font for Windows, the platform ID should be 3 and the
encoding ID should be 1. When building a symbol font for Windows, the platform
ID should be 3 and the encoding ID should be 0."
We were ignoring the SYMBOL_CS entry before. It's UTF-16/UCS-2 like the
UNICODE_CS.
Also, always use UTF-16BE instead of UCS-2BE. The conversion was doing
UTF-16BE anyway.
Akira TAGOH
Behdad Esfahbod
Marius Tolzmann
Mark Brand
Mikhail Gusarov
Keith Packard
Jeremy Huddleston
Mike Frysinger
Tor Lillqvist