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
A while back we removed Apple Roman encoding support. This broke
symbol fonts (Wingdings, etc) because those fonts come with two
cmaps:
1) platform=1,encoding=0, aka Apple Roman, which maps identity,
2) platform=3,encoding=0, aka MS Symbol font
Now, the reason the Apple Roman removal "broke" these fonts is
obvious, and for the better: these fonts were mapping ASCII and
other Latin chars to symbols.
The reason the fonts didn't work anymore, however, is that we were
mishandling the MS symbol-font cmaps. In their modern incarnation
they are like regular non-symbol-font cmap that map PUA codepoints
to symbols. We want to expose those as such. Hence, this change
just removes the special-handling for that.
Now, the reason this confusion happened, if I was to guess, is either
that FreeType docs are wrong saying that FT_ENCODING_MS_SYMBOL is
the "Microsoft Symbol encoding, used to encode mathematical symbols":
http://www.kostis.net/charsets/symbol.htm
or maybe it started that way, but turned into also mapping MS symbol-
font cmaps, which is a completely different thing. At any rate, I
don't know if there are any fonts that use this thing these days, but
the code here didn't seem to produce charset for any font. By now I'm
convinced that this change is the Right Thing to do. The MS Symbol
thing was called AdobeSymbol in our code by the way.
This fixes the much-reported bug that windings, etc are not usable
with recent fontconfig:
https://bugs.freedesktop.org/show_bug.cgi?id=58641
Now I see PUA mappings reported for Wingdings.
This also fixes:
Bug 48947 - Drop the non-Unicode cmap support gradually
https://bugs.freedesktop.org/show_bug.cgi?id=48947
since the AdobeSymbol was the last non-Unicode cmap we were
trying to parse (very incorrectly).
Lots of code around this change can be simplified. I'll push those
out (including removing the table itself) in subsequent changes.
All color fonts are designed to be scaled, even if they only have
bitmap strikes. Client is responsible to scale the bitmaps. This
is in constrast to non-color strikes...
Clients can still use FC_OUTLINE to distinguish bitmap vs outline
fonts. Previously FC_OUTLINE and FC_SCALABLE always had the same
value. Now FC_SCALABLE is set to (FC_OUTLINE || FC_COLOR).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=87122
This reverts commit a5a384c5ff.
I don't remember what I had in mind for "We will use this property later.", but
the change was wrong. If a font pattern doesn't have any value for element,
it must be interpretted as "it matches any value perfectly. And "perfectly"
must have a score of 0 for that to happen.
This was actually affecting bitmap fonts (in a bad way), as the change made
an outline font to always be preferred over a (otherwise equal) bitmap font,
even for the exact size of the bitmap font. That probably was never noticed
by anyone, but with the font range support this has become clear (and worked
around by Akira). To clean that up, I'm reverting this so I can land the
rest of patches for bug 80873.
https://bugs.freedesktop.org/show_bug.cgi?id=80873#c10
Previously, if the patten didn't request, eg, style, then the style
and stylelang were fully copied from the font, even though the pattern
had a stylelang. Eg:
$ fc-match 'Apple Color Emoji:stylelang=en'
Apple Color Emoji.ttf: "Apple Color Emoji" "標準體"
This change both fixes that and makes the code much more readable. Now:
$ fc-match 'Apple Color Emoji:stylelang=en'
Apple Color Emoji.ttf: "Apple Color Emoji" "Regular"
iconv support was turned off by default in f30a5d76.
Some fonts, like Apple Color Emoji, only have their English
name in a MacRoman entry. As such, decode MacRoman ourselves.
Previous format was unusable. New format is ranges of hex values.
To choose space character and Latin capital letters for example:
$ fc-pattern ':charset=20 41-5a'
Pattern has 1 elts (size 16)
charset:
0000: 00000000 00000001 07fffffe 00000000 00000000 00000000 00000000 00000000
(s)
It was added without proper measurement and a fuzzy possible
use-case (font servers) in mind, but reality check shows that
this significantly slows down caching. As such, deprecate it
and do NOT compute hash during caching.
Makes caching two to three times faster (ignoring the 2 second
delay in fc-cache).
This is more robust but introduces a small change in behavior:
For .pcf.gz fonts, the new code calculates the hash of the uncompressed
font data whereas the original code was calculating the hash of the
compressed data.
No big deal IMO.
FcTypeVoid is likely to happen when 'lang' and 'charset'
is deleted by 'delete' or 'delete_all' mode in edit.
Without this change, any modification on them are simply
ignored.
This is useful to make a lot of changes, particularly
when one wants to add a few and delete a lot say.
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.
Let me show it with an example.
Currently:
$ fc-match symbol
symbol.ttf: "Symbol" "Regular"
$ fc-match symbol --sort | head -n 1
Symbol.pfb: "Symbol" "Regular"
$ fc-match symbol --sort --all | head -n 1
symbol.ttf: "Symbol" "Regular"
I want to make sure the above three commands all return the same font.
Ie. I want to make sure FcFontMatch() always returns the first font
from FcFontSort(). As such, never trim first font.
Reported by parfait 1.3:
Error: Null pointer dereference (CWE 476)
Read from null pointer t
at line 423 of src/fcname.c in function 'FcNameParse'.
Function _FcObjectLookupOtherTypeByName may return constant 'NULL'
at line 63, called at line 122 of src/fcobjs.c in function
'FcObjectLookupOtherTypeByName'.
Function FcObjectLookupOtherTypeByName may return constant 'NULL'
at line 122, called at line 67 of src/fcname.c in function
'FcNameGetObjectType'.
Function FcNameGetObjectType may return constant 'NULL' at line 67,
called at line 422 in function 'FcNameParse'.
Null pointer introduced at line 63 of src/fcobjs.c in function
'_FcObjectLookupOtherTypeByName'.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reported by parfait 1.3:
Memory leak of pointer sset allocated with FcStrSetCreate()
at line 933 of src/fcstr.c in function 'FcStrBuildFilename'.
sset allocated at line 927 with FcStrSetCreate().
sset leaks when sset != NULL at line 932.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
config.h is read from fcint.h now so having a line of the sort of #include "config.h"
is duplicate.
Bug 69833 - Incorrect SIZEOF_VOID_P and ALIGNOF_DOUBLE definitions causes nasty warnings on MacOSX when building fat libraries
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
After this change, the following works as expected:
$ FC_DEBUG=4 fc-match ":family=foo bar, sans-serif"
...
FcConfigSubstitute Pattern has 3 elts (size 16)
family: "foo bar"(s) "sans-serif"(s)
...
Workaround to not failing even when the hash is unable to generate from fonts.
This change also contains to ignore the case if the hash isn't in either both
patterns.
Regex is expensive to compare filenames. we already have the glob matching
and it works enough in this case.
Prior to this change, renaming FcConfigGlobMatch() to FcStrGlobMatch() and moving to fcstr.c
Add back FcHashGetSHA256DigestFromFile() and fall back to it
when font isn't SFNT-based font because FT_Load_Sfnt_Table
fails with FT_Err_Invalid_Face_Handle.
As of automake-13.1 the INCLUDES directive is no longer supported.
An automake run will return with an error.
This changeset simply follows automake's advice to replace INCLUDES
by AM_CPPFLAGS.
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.
Last night in between my dreams I also noticed that we support Unicode
values up to 0x01000000 and not 0x00100000 which I thought before.
This covers the entire Unicode range.
Protect cache against future expansions of FcLangSet (adding new
orth files). Previously, doing so could change the size of
that struct. Indeed, that happened between 2.6.0 and 2.7.3, causing
crashes. Unfortunately, sizeof(FcLangSet) was not checked in fcarch.c.
This changes FcLangSet code to be able to cope with struct size changes.
And change cache format, hence bumping from 2 to 3.
Before a NULL config was passed down adn essentially FcFileScan was
equivalent to FcFreeTypeQuery. Now fc-scan tool correctly applies
the configuration to the scanned patterns.
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.
Fontconfig assigns an index number to each language it knows about.
The index is used to index a bit in FcLangSet language map. The bit
map is stored in the cache.
Previously fc-lang simply sorted the list of languages and assigned
them an index starting from zero. Net effect is that whenever new
orth files were added, all the FcLangSet info in the cache files would
become invalid. This was causing weird bugs like this one:
https://bugzilla.redhat.com/show_bug.cgi?id=490888
With this commit we fix the index assigned to each language. The index
will be based on the order the orth files are passed to fc-lang. As a
result all orth files are explicitly listed in Makefile.am now, and
new additions should be made to the end of the list. The list is made
to reflect the sorted list of orthographies from 2.6.0 released followed
by new additions since.
This fixes the stability problem. Needless to say, recreating caches
is necessary before any new orthography is recognized in existing fonts,
but at least the existing caches are still valid and don't cause bugs
like the above.
The format '%{[]family,familylang{expr}}' expands expr once for the first
value of family and familylang, then for the second, etc, until both lists
are exhausted.
The '%{=unparse}' format expands to the FcNameUnparse() result on the
pattern. Need to add '%{=verbose}' for FcPatternPrint() output but
need to change that function to output to a string first.
Also added the '%{=fclist}' and '%{=fcmatch}' which format like the
default format of fc-list and fc-match respectively.
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
Akira TAGOH
Behdad Esfahbod
Michael Haubenwallner
Alan Coopersmith
Sebastian Freundt
Marius Tolzmann
Mark Brand
Mikhail Gusarov
Keith Packard
Jeremy Huddleston
Mike Frysinger
Tor Lillqvist
Karl Tomlinson
Serge van den Boom
Karl Tomlinson