Mike Frysinger [Tue, 8 Nov 2011 19:19:57 +0000 (14:19 -0500)]
makealias: handle missing funcs better
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.
Mike Frysinger [Mon, 7 Nov 2011 20:33:12 +0000 (15:33 -0500)]
fc-{list,match}: constify format string
We don't free this string anywhere, so mark it const to avoid gcc warnings
and possible bugs in the future (if people did try freeing it).
fc-list.c: In function 'main':
fc-list.c:161:16: warning: pointer targets in assignment
differ in signedness [-Wpointer-sign]
fc-match.c: In function 'main':
fc-match.c:201:13: warning: pointer targets in assignment
differ in signedness [-Wpointer-sign]
fc-match.c:203:13: warning: pointer targets in assignment
differ in signedness [-Wpointer-sign]
Mike Frysinger [Mon, 7 Nov 2011 20:26:52 +0000 (15:26 -0500)]
FcName{,Get}Constant: constify string input
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 *'
Mike Frysinger [Mon, 7 Nov 2011 20:24:53 +0000 (15:24 -0500)]
fc-cat: fix pointer warning
Add a cast to avoid a gcc warning:
fc-cat.c: In function 'cache_print_set':
fc-cat.c:230:2: warning: pointer targets in passing argument 2
of 'FcPatternFormat' differ in signedness [-Wpointer-sign]
../fontconfig/fontconfig.h:860:1: note:
expected 'const FcChar8 *' but argument is of type 'char *'
Mike Frysinger [Mon, 7 Nov 2011 20:21:51 +0000 (15:21 -0500)]
FcStat: change to FcChar8 for first arg
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.
Behdad Esfahbod [Mon, 20 Jun 2011 15:22:17 +0000 (11:22 -0400)]
Bug 26718 - "fc-match sans file" doesn't work
- 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.
Behdad Esfahbod [Mon, 20 Jun 2011 15:07:56 +0000 (11:07 -0400)]
Bug 36577 - Updating cache with no-bitmaps disables bitmap fonts...
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.
fontconfig.pc.in: Add sysconfdir, localstatedir, and PACKAGE
In the default case, cachedir and confdir will evaluate to something
referencing these other variables (which wouldn't otherwise be defined
in the pkg-config file.
Accept TT_PLATFORM_MICROSOFT, TT_MS_ID_SYMBOL_CS from name table
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.
Behdad Esfahbod [Wed, 18 Nov 2009 14:10:05 +0000 (09:10 -0500)]
Remove bogus comment
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.
Behdad Esfahbod [Mon, 16 Nov 2009 20:39:16 +0000 (15:39 -0500)]
Bump cache version up from 2 to 3 and fix FcLangSet caching/crash
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.