GitLab

Patch from Theppitak Karoonboonyanan

The fact that we now drop final slashes from all filenames without
checking that the file name represents a directory may surprise some,
but it doesn't bother me really.

Signed-off-by: Keith Packard <keithp@keithp.com>

An empty element would cause every file starting with the current
directory to be scanned, probably not what the user wanted.

fc-cache lives in $(bindir)/fc-cache, not $(bindir)/fc-cache/fc-cache.

To make static linking work, fontconfig.pc needs @FREETYPE_LIBS@ in
Libs.private.

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.

It seems indices in _FcMatchers array are slightly mixed up, MATCH_DECORATIVE
should be 10, not 11.

And MATCH_RASTERIZER_INDEX should be 13, not 12, right?

When building in Win32 e.g. with MinGW, the install tries to run fc-cache
locally but the required DLL's are not in the path. I've included a patch for
this to fix Makefile.in to run fc-cache from bindir but obviously this should
be applied to Makefile.am instead.

(the second part of this patch was already in the tree)

Description of FcStrDirname is absent in the official documentation of
fontconfig-2.5.92. At the same time the source documentation contains
description of the function.

The problem is a consequence of a misprint in the format of the source
documentation file 'fcstring.fncs'. The finish mark of description of the
previous function is absent.

An ancient version of dolt.m4 was installed on my system leading to a broken
build on non-Linux systems.

Autohinting for Indic fonts has been disabled since freetype could not handle
it properly. But since freetype-2.3.5, the hinting problems for indic fonts
have been fixed. Thus this is a request to enable the autohinting in
fontconfig again for all the indic fonts.

extended -> expanded.
caps, dunhill -> decorative

The built-in memory tracking code in fontconfig relies on a lot of manual
function call tracking. A pain, but it helps debug leaks.

FcFini frees all libary data structures so valgrind should report 0
allocations in use when the program exits.

Libtool-2.2 introduces new restrictions. So now it does not allow LT_*
variables as it includes marcros:

m4_pattern_forbid([^_?LT_[A-Z_]+$])

Rename the LT_ variables to LIBT_ to work around this restriction.

With PUBLIC_FILES no longer containing the freetype-dependent symbols, those
must be added to the fontconfig.def file build process.

Building 2.5.91 on Solaris with the native make(1) yields

...
Making all in src
make: Fatal error in reader: Makefile, line 313: Unexpected end of line seen
Current working directory /tmp/fontconfig-2.5.91/src
*** Error code 1

This is due to the following line (src/Makefile.am:143):

    CLEANFILES := $(ALIAS_FILES)

Changing that to a standard assignment ("=") fixes the problem.

I believe the ":=" is a typo. ALIAS_FILES is just a statically assigned
variable; it's not like evaluating it more than once would be a problem.

If the /usr/bin/head program is missing or unusable, or if an unusable head
program is listed first in the PATH, fontconfig fails to build

using "sed -n 1p" instead of "head -1" would be a suitable workaround.

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.

I propose to replace the default Baekmuk Korean fonts with Un fonts.

Some people don't agree but most Korean people prefer Un fonts to Baekmuk
ones.  Un fonts just look better, at least in the most common Linux desktops
(antialiased, GNOME or KDE, high resolution).