Recently some python scripts has been added to the build toolchain for meson build support. but we don't want to maintain multiple files for one purpose. since autotools build support will be guradually discontinued, integrating those scripts into autotools would be better.
This avoids a situation where the score of lang becomes lower or equal to others
and then figures out the best font according to other properties and the order
of family names.
This typically happens only when our orthography files are the subset of lang
in patterns. i.e. fc-match :lang=en-us to match on en.orth.
In this case, the score is lower than the exact match (en to en) and the partial
match (en to en-us). thus, the result of 'fc-match :lang=en-us' isn't necessarily
same to 'fc-match :lang=en'.
So 35-lang-normalize.conf contains languages only which is available as orth
without countries and tries to update properties to match on orth exactly like:
<match>
<test name="lang" compare="contains">
<string>en</string>
</test>
<edit name="lang" mode="assign" binding="same">
<string>en</string>
</edit>
</match>
Fixes https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/155
Previously we were failing if CROSS_COMPILING and the generated headers
were not present. It works just fine now.
One caveat: the fix is not fully correct since config.h is being
included in the files built with CC_FOR_BUILD, but config.h has config
for the host system, not the build system. Should be fine though.
When ./configure'd in a directory other than the srcdir, we need to look
in ${top_builddir)/src for the generated header fcstdint.h
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
The correct ISO 639 code for Pakistani/Western Panjabi seems to be 'lah',
not 'pa'. We are keeping 'pa_pk.orth' for compatiblity with glibc.
Signed-off-by: Behdad Esfahbod <behdad@behdad.org>
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.
If the generated header files are included in the distribution, a build
outside of the source directory will use them. For machine-specific files,
this generates the wrong result (fcarch.h). Leaving them out of the
distribution forces them to be built.
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
clean up .spec file; perhaps this will be useful to somebody...
Update to 2.2.93
Make 'scanopen' static so GCC doesn't whine about lacking prototype
Add WARN_CFLAGS to pass -W flags for GCC systems
Change various char types around to match across function calls. Fixed bug
in using available_sizes[i].height which is in pixels, not 64ths of a
pixel.
but there are still failures long into the process dealing with docs
(as always).
The big changes here are mostly to make $(srcdir) != "." work correctly,
fixing the docbook related sections and fc-lang were particularily
tricky. Docbook refuses to load system entities from anywhere other
than where the original .sgml file was located, so no luck looking in
"." for the configure-generated version.sgml and confdir.sgml files.
fc-lang needed help finding .orth files; added a -d option to set the
directory as the least evil of many options.
Now to go use a faster machine and try and wring out the last issues.