A private FcObjectGetSet() is implemented that provides an
FcObjectSet of all registered elements. FcFontSetList() is
then modified to use the object set from FcObjectGetSet() if
provided object-set is NULL.
Alternatively FcObjectGetSet() can be made public. In that
case fc-list can use that as a base if --verbose is included,
and also add any elements provided by the user (though that has
no effect, as all elements from the cache are already registered).
Currently fc-list ignores user-provided elements if --verbose
is specified.
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.
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.
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.
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.
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).
Behdad Esfahbod
Benjamin Close
Peter
Keith Packard
Sayamindu Dasgupta
Evgeniy Stepanov
Glen Low
Neskie Manuel
Behdad Esfahbod
Alexey Khoroshilov
Carlo Bramini
Ryan Schmidt
Dennis Schridde
Changwoo Ryu