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).
This feature requires the FreeType 2.5.1 or later at the build time.
Besides <range> element allows <double> elements with this changes.
This may breaks the cache but not bumping in this change sets at this moment.
please be aware if you want to try it and run fc-cache before/after to
avoid the weird thing against it.
This change reverts 9acc14c34a
because it doesn't work as expected when building
with -fshort-enums which is default for older arms ABIs
Thanks for pointing this out, Thomas Klausner, Valery Ushakov, and Martin Husemann
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>
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.
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.
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.
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 East Asian double-byte codepages have characters with backslash as
the second byte, so we must use _mbsrchr() instead of strrchr() when
looking at pathnames in the system codepage.
Must not call FcStrFree() on a value returned by
FcStrBufDoneStatic(). In the Windows code don't bother with dynamic
allocation, just use a local buffer.
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.
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.
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.
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.
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
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.
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.
Akira TAGOH
Behdad Esfahbod
Руслан Ижбулатов
Marius Tolzmann
Mark Brand
Tor Lillqvist
Harald Fernengel
Keith Packard
Dennis Schridde
Keith Packard
Mike FABIAN
Keith Packard
Patrick Lam