fontconfig issueshttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues2019-12-08T10:47:47Zhttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/56RFE: fontconfig-level locl patching2019-12-08T10:47:47ZBugzilla Migration UserRFE: fontconfig-level locl patching## Submitted by Nicolas Mailhot
Assigned to **fon..@..op.org**
**[Link to original bug (#18723)](https://bugs.freedesktop.org/show_bug.cgi?id=18723)**
## Description
Due to Han unification and other similar stuff parts of some fon...## Submitted by Nicolas Mailhot
Assigned to **fon..@..op.org**
**[Link to original bug (#18723)](https://bugs.freedesktop.org/show_bug.cgi?id=18723)**
## Description
Due to Han unification and other similar stuff parts of some fonts may not be suitable for all locales.
This is handled by the locl flag in modern opentype fonts.
However there are still many non-opentype fonts in the wild, and it is not possible to convert them all at once (when the license permits it).
There should be a way in fontconfig for font distributors to patch in via a config file the locl characteristics of a font.
Version: 2.6https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/54No language tag modifiers support2018-08-20T21:47:46ZBugzilla Migration UserNo language tag modifiers support## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#42900)](https://bugs.freedesktop.org/show_bug.cgi?id=42900)**
## Description
There are no modifiers support in fontconfig, particularly ...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#42900)](https://bugs.freedesktop.org/show_bug.cgi?id=42900)**
## Description
There are no modifiers support in fontconfig, particularly in FcGetDefaultLang() and FcLang*
Version: 2.8
### Blocking
* [Bug 25647](https://bugs.freedesktop.org/show_bug.cgi?id=25647)
* [Bug 25648](https://bugs.freedesktop.org/show_bug.cgi?id=25648)
* [Bug 25650](https://bugs.freedesktop.org/show_bug.cgi?id=25650)
* [Bug 25652](https://bugs.freedesktop.org/show_bug.cgi?id=25652)
* [Bug 27849](https://bugs.freedesktop.org/show_bug.cgi?id=27849)
* [Bug 27850](https://bugs.freedesktop.org/show_bug.cgi?id=27850)https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/50fontconfig should change to BCP 47 language tags2019-12-08T10:44:30ZBugzilla Migration Userfontconfig should change to BCP 47 language tags## Submitted by Roozbeh Pournader
Assigned to **fon..@..op.org**
**[Link to original bug (#19869)](https://bugs.freedesktop.org/show_bug.cgi?id=19869)**
## Description
Presently, the language model for fontconfig is based on the R...## Submitted by Roozbeh Pournader
Assigned to **fon..@..op.org**
**[Link to original bug (#19869)](https://bugs.freedesktop.org/show_bug.cgi?id=19869)**
## Description
Presently, the language model for fontconfig is based on the RFC 3066 model of language tags, which is not future-proof. The language model should switch to that of current BCP 47 (RFC 4646). Or an extended version that adds ISO 639-3 codes (RFC 4646bis): the ISO 639-3 codes are already in use in various localization communities.
The main difference would be supporting script subtags. An HTML author may have Kurdish in the Arabic script, and it wouldn't care/know if it's for Iran or Iraq. So it can tag that part of the page as ku-Arab. The browser can later request fonts for ku-Arab from fontconfig, instead of automagically finding it is probably ku-IR to fontconfig.
For existing glibc locales, and applications that use that data to render fonts (pango?), "@" would translate to "-x-", converting locales like sr_RS@latin to valid BCP 47 tags like "sr-RS-x-latin" which we can support as an alias/copy of sr-Latn. This way, we would be handling glibc tags as what they really are: private use subtags. Alternatively, we can ask the applications to convert sr_RS@latin to sr-Latn-RS themselves somehow, which we will match with our sr-Latn.
This would also make maintaining orth files somehow easier and cleaner, as the languages written in different scripts won't be separated by countries, but by scripts. We will have a ku-Arab, with ku-IR and ku-IQ aliasing/including it, a ku-Latn, with ku-TR aliasing it, and a ku-Cyrl, with no alias until we find more information on which Kurdish .
Over time, country code language codes are supposed to disappear, so if somebody really wants ku-IR, he SHOULD say "ku-Arab-IR", which makes matching and everything much easier too.
Version: 2.6
### Blocking
* [Bug 17208](https://bugs.freedesktop.org/show_bug.cgi?id=17208)https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/49[patch] Allow fontconfig to use 3 components in locales2018-08-20T21:46:25ZBugzilla Migration User[patch] Allow fontconfig to use 3 components in locales## Submitted by Koop Mast
Assigned to **fon..@..op.org**
**[Link to original bug (#92776)](https://bugs.freedesktop.org/show_bug.cgi?id=92776)**
## Description
Created attachment 119343
Support 3 component locales
Linux only supp...## Submitted by Koop Mast
Assigned to **fon..@..op.org**
**[Link to original bug (#92776)](https://bugs.freedesktop.org/show_bug.cgi?id=92776)**
## Description
Created attachment 119343
Support 3 component locales
Linux only supports locales with 2 components while POSIX supports
locales with 3 components.
DragonFly and FreeBSD both follow POSIX, which causes fontconfig to
give the following warning:
% env LC_CTYPE=sr_Cyrl_RS.UTF-8 leafpad
Fontconfig warning: ignoring sr_Cyrl_RS.UTF-8: not a valid region tag
For more information about the POSIX documentation:
http://tools.ietf.org/html/bcp47
Chapter 2.1.1 goes over formatting and Appendix-A has more examples.
**Patch 119343**, "Support 3 component locales":
[0001-Support-3-component-locales.patch](/uploads/a49842028169b9604a3b4bf52b4284a1/0001-Support-3-component-locales.patch)
Version: 2.11https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/47Add a FC_LOCALE_LANG element2018-08-20T21:46:18ZBugzilla Migration UserAdd a FC_LOCALE_LANG element## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#17311)](https://bugs.freedesktop.org/show_bug.cgi?id=17311)**
## Description
This would be quite similar to FC_LANG, except that it holds the...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#17311)](https://bugs.freedesktop.org/show_bug.cgi?id=17311)**
## Description
This would be quite similar to FC_LANG, except that it holds the default language of the locale, not the language we are looking for fonts for.
The idea is that an application (Pango) looking for a font to render English always passes en as lang. However, in CJK locales, it may be desirable to select the same font for Latin as well as CJK. With the proposed element, a conf file can check whether FC_LOCALE_LANG is CJK and in that case, add the CJK font as the single preferred font. All this without affecting the case of not running under a CJK locale.
Version: 2.4https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/46Postscript name matching issues2019-06-21T08:12:08ZBugzilla Migration UserPostscript name matching issues## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#107242)](https://bugs.freedesktop.org/show_bug.cgi?id=107242)**
## Description
Dominik and I are looking at postscriptname matching in Chrome...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#107242)](https://bugs.freedesktop.org/show_bug.cgi?id=107242)**
## Description
Dominik and I are looking at postscriptname matching in Chrome, and I found a couple issues with it.
1. The code seems to want to ignore space and dash as delimiters:
```
static double
FcComparePostScript (const FcValue *v1, const FcValue *v2, FcValue *bestValue)
{
const FcChar8 *v1_string = FcValueString (v1);
const FcChar8 *v2_string = FcValueString (v2);
int n;
size_t len;
*bestValue = FcValueCanonicalize (v2);
if (FcToLower (*v1_string) != FcToLower (*v2_string) &&
↦ *v1_string != ' ' && *v2_string != ' ')
↦ return 1.0;
n = FcStrMatchIgnoreCaseAndDelims (v1_string, v2_string, (const FcChar8 *)" -");
len = strlen ((const char *)v1_string);
return (double)(len - n) / (double)len;
}
```
But in actual testing I don't see dash ignored. NOT ignoring dash is actually correct and desired behavior. I just don't understand why it's not ignored by the code currently.
Inside FcStrCaseWalkerNext(), delims are not checked when fulfilling request from w->read:
```
static FcChar8
FcStrCaseWalkerNext (FcCaseWalker *w, const char *delims)
{
FcChar8↦ r;
if (w->read)
{
↦ if ((r = *w->read++))
↦ return r;
↦ w->read = 0;
}
do
{
↦ r = *w->src++;
} while (r != 0 && delims && strchr (delims, r));
if ((r & 0xc0) == 0xc0)
↦ return FcStrCaseWalkerLong (w, r);
if ('A' <= r && r <= 'Z')
r = r - 'A' + 'a';
return r;
}
```
Ie, `if ((r = *w->read++))` needs to also check delims...https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/42lang attribute support for family tag2018-08-20T21:45:54ZBugzilla Migration Userlang attribute support for family tag## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#68377)](https://bugs.freedesktop.org/show_bug.cgi?id=68377)**
## Description
`<family>` tag is used for `<alias>` though, sometimes want...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#68377)](https://bugs.freedesktop.org/show_bug.cgi?id=68377)**
## Description
`<family>` tag is used for `<alias>` though, sometimes wants to add the family conditionally, particularly for certain language. `<alias>` is capable to have `<test>` elements but may be a good idea to have the lang attribute to `<family>` as another syntactic sugar:
`<alias>`
`<family>`serif`</family>`
`<prefer>`
...
`<family lang="ja">`MS Mincho`</family>`
<family lang="zh-cn,zh-tw">AR PL ShanHeiSun Uni`</family>`
...
`</prefer>`
`</alias>`
interpreted like:
`<match>`
`<test name="family">`
`<string>`serif`</string>`
`</test>`
`<test name="lang">`
`<string>`ja`</string>`
`</test>`
`<edit name="family" mode="prepend">`
`<string>`MS Mincho`</string>`
`</edit>`
`</match>`
`<match>`
`<test name="family">`
`<string>`serif`</string>`
`</test>`
`<test name="lang">`
`<string>`zh-cn`</string>`
`</test>`
`<edit name="family" mode="prepend">`
`<string>`AR PL ShanHeiSun Uni`</string>`
`</edit>`
`</match>`
`<match>`
`<test name="family">`
`<string>`serif`</string>`
`</test>`
`<test name="lang">`
`<string>`zh-tw`</string>`
`</test>`
`<edit name="family" mode="prepend">`
`<string>`AR PL ShanHeiSun Uni`</string>`
`</edit>`
`</match>`https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/41objects for target="pattern" is inherited to the result of FcMatchFont2018-08-20T21:45:51ZBugzilla Migration Userobjects for target="pattern" is inherited to the result of FcMatchFont## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#53323)](https://bugs.freedesktop.org/show_bug.cgi?id=53323)**
## Description
The quote from the document:
use rgb sub-pixel ord...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#53323)](https://bugs.freedesktop.org/show_bug.cgi?id=53323)**
## Description
The quote from the document:
use rgb sub-pixel ordering to improve glyph appearance on
LCD screens. Changes affecting rendering, but not matching
should always use target="font".
So the following rule should be affected to the result of FcPattern for FcMatchFont:
`<match target="pattern">`
`<edit name="rgba" mode="assign">`
`<const>`rgb`</const>`
`</edit>`
`</match>`
but it does:
$ fc-match -v | grep rgba
rgba: 1(i)(s)
This behavior messes up the rule of target="font".
Aside from that, right now fontconfig warns when editing the user-defined object on target="scan" though, we should do it for others if it's not desirable and for target="pattern" and target="font" too.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/37Provide FcFontSort-like API without having the fallbacks2018-08-20T21:45:34ZBugzilla Migration UserProvide FcFontSort-like API without having the fallbacks## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#8053)](https://bugs.freedesktop.org/show_bug.cgi?id=8053)**
## Description
Keith has this idea of for performance reasons rebuilding FcFontSo...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#8053)](https://bugs.freedesktop.org/show_bug.cgi?id=8053)**
## Description
Keith has this idea of for performance reasons rebuilding FcFontSort results
from FcFontMatch followed by a generic fallback list. This doesn't work for
various cases, including for ":lang=en,ja" for example.
To be able to do something like that we need a new API that returns a list of
fonts explicitly chosen to fulfill the requested pattern (including stuff added
by the config file.) That list then can be expanded by a generic fallback list
by the application. Not sure how easy is to implement this.
Example:
[behdad@home ~]$ fc-match --sort | head -n 5
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans-ExtraLight.ttf: "DejaVu LGC Sans" "ExtraLight"
DejaVuLGCSans-BoldOblique.ttf: "DejaVu LGC Sans" "Bold Oblique"
n019003l.pfb: "Nimbus Sans L" "Regular"
[behdad@home ~]$ fc-match --sort :lang=fa | head -n 5
roya.ttf: "Roya" "Regular"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans-ExtraLight.ttf: "DejaVu LGC Sans" "ExtraLight"
DejaVuLGCSans-BoldOblique.ttf: "DejaVu LGC Sans" "Bold Oblique"
[behdad@home ~]$ fc-match --sort :lang=fa,ja | head -n 5
roya.ttf: "Roya" "Regular"
sazanami-gothic.ttf: "Sazanami Gothic" "Gothic-Regular"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans-ExtraLight.ttf: "DejaVu LGC Sans" "ExtraLight"
[behdad@home ~]$ fc-match --sort Nazli:lang=fa,ja | head -n 5
nazli.ttf: "Nazli" "Regular"
sazanami-gothic.ttf: "Sazanami Gothic" "Gothic-Regular"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans.ttf: "DejaVu LGC Sans" "Book"
DejaVuLGCSans-ExtraLight.ttf: "DejaVu LGC Sans" "ExtraLight"
Version: 2_1https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/36Make fc-query warn about non-WWS compliant fonts2019-12-08T10:39:08ZBugzilla Migration UserMake fc-query warn about non-WWS compliant fonts## Submitted by Nicolas Mailhot
Assigned to **fon..@..op.org**
**[Link to original bug (#22338)](https://bugs.freedesktop.org/show_bug.cgi?id=22338)**
## Description
(it would be nice if there was a fc-query component in fontconfi...## Submitted by Nicolas Mailhot
Assigned to **fon..@..op.org**
**[Link to original bug (#22338)](https://bugs.freedesktop.org/show_bug.cgi?id=22338)**
## Description
(it would be nice if there was a fc-query component in fontconfig BTW)
Since MS' WWS naming model makes stuff simpler for application authors, and will be required in new window code, it would be mighty nice if fc-query warned in its general report if a font file didn't respect this model.
Respecting the WWS model is declaring fields 21 and 22 or 16 in 17 in ways that respect WWS (only weight, width and slant in sytles)
This way we can point FLOSS authors to fc-query as linting tools and promote font naming our apps can handle easily
Version: 2.6https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/34Optimize family name matching in sort and match functions2021-02-22T19:24:04ZBugzilla Migration UserOptimize family name matching in sort and match functions## Submitted by Karl Tomlinson
Assigned to **fon..@..op.org**
**[Link to original bug (#19376)](https://bugs.freedesktop.org/show_bug.cgi?id=19376)**
## Description
Currently the time for a FcFont(Set)Sort with trim = false (or fo...## Submitted by Karl Tomlinson
Assigned to **fon..@..op.org**
**[Link to original bug (#19376)](https://bugs.freedesktop.org/show_bug.cgi?id=19376)**
## Description
Currently the time for a FcFont(Set)Sort with trim = false (or for a
FcFont(Set)Match) I assume) is typically dominated by comparing family names.
By the time aliases are added to the sort pattern there are typically 80-100
family names in the pattern (p). For 300 to 500 fonts (some of which will
have family names for each language) (n), that is p * n ~ 40,000
case-insensitive string comparisons.
I think a sensible approach to optimizing this would be to sort the families
in the sort pattern (removing duplicates, recording the score for each family,
and remembering to consider the binding) so that each family lookup is
O(log p) and the total complexity is O((n + p) log p).
This would be faster whenever n >> log p, which is almost always the case.
(Behdad was considering something similar. I think this is slightly different
from what Behdad had in mind, but perhaps he thought of this too.)
(I guess the same argument could be applied to any (sortable) property, but it
is typically only family properties that have so many values.)
(The sorted family list is essentially a cheap hash table. I'm guessing that
looking up a family in a sorted list is going to be cheaper ~O(log p), assuming there are not too many similar family names), than generating a hash for the family O(length of string).)
Version: 2_1https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/33Support ISO 14496-28 Composite Font Representation2020-04-02T13:28:21ZBugzilla Migration UserSupport ISO 14496-28 Composite Font Representation## Submitted by Sascha Brawer
Assigned to **fon..@..op.org**
**[Link to original bug (#96693)](https://bugs.freedesktop.org/show_bug.cgi?id=96693)**
## Description
Could fontconfig support the Composite Font Representation of ISO ...## Submitted by Sascha Brawer
Assigned to **fon..@..op.org**
**[Link to original bug (#96693)](https://bugs.freedesktop.org/show_bug.cgi?id=96693)**
## Description
Could fontconfig support the Composite Font Representation of ISO 14496-28?
https://blogs.adobe.com/CCJKType/2012/04/cfr.html
At Google, we’re considering to release CFR files for grouping the myriad of Noto fonts into a few families such as "Noto Sans", "Noto Serif", and "Noto Mono". The total number of glyphs exceeds 64K, so we cannot just ship Noto Sans etc. as one gigantic OpenType file. Instead, we need a mechanism for declaring a virtual font. CFR has the advantage of being standardized. However, as of June 2016, Apple is the only platform that implements CFR. But perhaps fontconfig could follow Apple in that regard? Anyhow, here’s a draft CFR file for Noto Sans, which might help to illustrate the CFR syntax:
https://github.com/googlei18n/noto-fonts/issues/707#issuecomment-224503236
For downloading the official specification document (+errata) from ISO, search for "14496-28" on this page:
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
— Sascha Brawer, sascha@brawer.ch / sascha@google.comhttps://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/30Prioritize fonts that support a territory-less language variant when no exact...2019-06-13T12:08:21ZBugzilla Migration UserPrioritize fonts that support a territory-less language variant when no exact language match## Submitted by Caolán McNamara
Assigned to **fon..@..op.org**
**[Link to original bug (#35118)](https://bugs.freedesktop.org/show_bug.cgi?id=35118)**
## Description
Created attachment 44237
implement suggestion
When fontconfig m...## Submitted by Caolán McNamara
Assigned to **fon..@..op.org**
**[Link to original bug (#35118)](https://bugs.freedesktop.org/show_bug.cgi?id=35118)**
## Description
Created attachment 44237
implement suggestion
When fontconfig matches by language tag, and the language tag supplied does not match exactly a known fontconfig language tag then fontconfig considers a list of all fonts that provide support for at least a variant language of the language tag.
It doesn't however prioritize fonts that support a territory-less variant, which is likely the best one to use under these circumstances.
i.e. practically
fc-match :lang=pa-IN
will generate a list of "pa" fonts and "pa-pk" fonts and fairly arbitrarily return one of that list.
so for me I get
"Droid Sans Arabic" because that supports "pa-pk", but anything that provided just "pa" would be a better choice.
e.g. see https://bugzilla.redhat.com/show_bug.cgi?id=682716
Attached is an implementation to effectively sort "xx" before "xx-*" when no exact "xx-yy" was found.
**Patch 44237**, "implement suggestion":
[sort.nonterritory.first.patch](/uploads/1e755759f3e889c0c825fefdaa4241de/sort.nonterritory.first.patch)
Version: 2.8https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/25RFE: Accessor functions to the structure members2022-07-01T06:16:03ZBugzilla Migration UserRFE: Accessor functions to the structure members## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#90923)](https://bugs.freedesktop.org/show_bug.cgi?id=90923)**
## Description
fontconfig should disallow the direct access to the structu...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#90923)](https://bugs.freedesktop.org/show_bug.cgi?id=90923)**
## Description
fontconfig should disallow the direct access to the structure members to applications. it keeps ABI compatibility in general and avoid unnecessary crashes against unexpected pointer access say.
maybe targeting on fontconfig3.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/24Include TTF_NAME table fields in fontconfig's cache2022-07-01T06:16:03ZBugzilla Migration UserInclude TTF_NAME table fields in fontconfig's cache## Submitted by Nicolas Spalinger
Assigned to **fon..@..op.org**
**[Link to original bug (#18340)](https://bugs.freedesktop.org/show_bug.cgi?id=18340)**
## Description
Please include in the fontconfig cache the information contain...## Submitted by Nicolas Spalinger
Assigned to **fon..@..op.org**
**[Link to original bug (#18340)](https://bugs.freedesktop.org/show_bug.cgi?id=18340)**
## Description
Please include in the fontconfig cache the information contained in the following fields of the NAME table to allow better exposure of the existing font metadata contained in both open and restricted fonts.
These are standard fields already taken into account in Freetype:
in include/freetype/ttnameid.h
#define TT_NAME_ID_COPYRIGHT 0
#define TT_NAME_ID_FONT_FAMILY 1
#define TT_NAME_ID_FONT_SUBFAMILY 2
#define TT_NAME_ID_UNIQUE_ID 3
#define TT_NAME_ID_FULL_NAME 4
#define TT_NAME_ID_VERSION_STRING 5
#define TT_NAME_ID_PS_NAME 6
#define TT_NAME_ID_TRADEMARK 7
#define TT_NAME_ID_MANUFACTURER 8
#define TT_NAME_ID_DESIGNER 9
#define TT_NAME_ID_DESCRIPTION 10
#define TT_NAME_ID_VENDOR_URL 11
#define TT_NAME_ID_DESIGNER_URL 12
#define TT_NAME_ID_LICENSE 13
#define TT_NAME_ID_LICENSE_URL 14
Then the cache can be queried for this information: utilities like fc-list or fc-match can report on the licensing/author/foundry for each font in the cache by default or via a parameter. Dedicated commands like fc-license could also be created.
Version: 2.6https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/23Element for whether FreeType's patented bytecode-interpretter is available2022-07-01T06:16:03ZBugzilla Migration UserElement for whether FreeType's patented bytecode-interpretter is available## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#17101)](https://bugs.freedesktop.org/show_bug.cgi?id=17101)**
## Description
And use it in FcDefaultSubstitute, such that user can choose hin...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#17101)](https://bugs.freedesktop.org/show_bug.cgi?id=17101)**
## Description
And use it in FcDefaultSubstitute, such that user can choose hinting/subpixel settings based on whether BCI is available.
This can be checked using:
#include <ft2build.h>
#include FT_CONFIG_OPTION_H
int has_bci =
#ifdef TT_CONFIG_OPTION_BYTECODE_INTERPRETER
1
#else
0
#endif
;
Other interesting option to expose is FT_CONFIG_OPTION_SUBPIXEL_RENDERING.
Version: 2.4https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/22Add desktopname object like prgname2022-07-01T06:16:03ZBugzilla Migration UserAdd desktopname object like prgname## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#96650)](https://bugs.freedesktop.org/show_bug.cgi?id=96650)**
## Description
That might be useful if someone wants to have different beh...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#96650)](https://bugs.freedesktop.org/show_bug.cgi?id=96650)**
## Description
That might be useful if someone wants to have different behavior in the configuration against current desktop session.
The usecase is e.g. the default hinting in GNOME is hintslight and KDE seems hintmedium. one may wants to have different default hinting for non native-desktop applications among desktops.
the desktopname object may be compared to $XDG_CURRENT_DESKTOP.https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/20switching-off libfontconfig.dll.a target if configured without shared lib.2022-07-01T06:16:03ZBugzilla Migration Userswitching-off libfontconfig.dll.a target if configured without shared lib.## Submitted by suzuki toshiya
Assigned to **fon..@..op.org**
**[Link to original bug (#26828)](https://bugs.freedesktop.org/show_bug.cgi?id=26828)**
## Description
Created attachment 33672
disable DLL targets if configured withou...## Submitted by suzuki toshiya
Assigned to **fon..@..op.org**
**[Link to original bug (#26828)](https://bugs.freedesktop.org/show_bug.cgi?id=26828)**
## Description
Created attachment 33672
disable DLL targets if configured without shared lib
src/Makefile.am has 2 DLL-related install targets for Win32,
install-libtool-import-lib and fontconfig.lib.
When I run configure --disable-shared --enable-static on
cygwin environment, libfontconfig.dll.a, libfontconfig-XXX.dll
are not built, so DLL-related targets are not installable.
So I propose to disable DLL-related targets when configured
without shared library, like this. Also patch is attached.
diff --git a/configure.in b/configure.in
index b4a27e9..001146d 100644
--- a/configure.in
+++ b/configure.in
@@ -67,6 +67,7 @@ AC_PROG_MAKE_SET
PKG_PROG_PKG_CONFIG
dnl ==========================================================================
+AM_CONDITIONAL(ENABLE_SHARED, test "$enable_shared" = "yes")
case "$host" in
*-*-mingw*)
@@ -76,11 +77,13 @@ case "$host" in
os_win32=no
esac
AM_CONDITIONAL(OS_WIN32, test "$os_win32" = "yes")
+AM_CONDITIONAL(BUILD_WIN32_DLL, test "$os_win32" = "yes" -a "$enable_shared" = "yes")
if test "$os_win32" = "yes"; then
AC_CHECK_PROG(ms_librarian, lib.exe, yes, no)
fi
AM_CONDITIONAL(MS_LIB_AVAILABLE, test x$ms_librarian = xyes)
+AM_CONDITIONAL(BUILD_MS_IMPORT_LIB, test x$ms_librarian = xyes -a "$enable_shared" = "yes")
WARN_CFLAGS=""
if test "x$GCC" = "xyes"; then
diff --git a/src/Makefile.am b/src/Makefile.am
index 406e85e..9110cde 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -21,7 +21,7 @@
# TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
# PERFORMANCE OF THIS SOFTWARE.
-if OS_WIN32
+if BUILD_WIN32_DLL
export_symbols = -export-symbols fontconfig.def
@@ -45,7 +45,7 @@ fontconfig_def_dependency =
endif
-if MS_LIB_AVAILABLE
+if BUILD_MS_IMPORT_LIB
# Microsoft import library install/uninstall
**Patch 33672**, "disable DLL targets if configured without shared lib":
[disable-dll.diff](/uploads/3a45751d0b64d1447aa6bdc5a1867f23/disable-dll.diff)
Version: 2_1https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/18FcNameParse() ignores non-builtin elements2022-07-01T06:16:03ZBugzilla Migration UserFcNameParse() ignores non-builtin elements## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#19331)](https://bugs.freedesktop.org/show_bug.cgi?id=19331)**
## Description
FcNameParse() only parses elements that it knows. That's becaus...## Submitted by Behdad Esfahbod
Assigned to **fon..@..op.org**
**[Link to original bug (#19331)](https://bugs.freedesktop.org/show_bug.cgi?id=19331)**
## Description
FcNameParse() only parses elements that it knows. That's because it needs to know the type of the element. I like to see it parse everything though, and it can do a heuristic at detecting the type, or look at the end of the value to see if there are type specifiers.
Version: 2.4https://gitlab.freedesktop.org/fontconfig/fontconfig/-/issues/17API redesign2022-07-01T06:16:03ZBugzilla Migration UserAPI redesign## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#48755)](https://bugs.freedesktop.org/show_bug.cgi?id=48755)**
## Description
there are some cases I feel an urge to cleanup/redesign fon...## Submitted by Akira TAGOH `@tagoh`
Assigned to **fon..@..op.org**
**[Link to original bug (#48755)](https://bugs.freedesktop.org/show_bug.cgi?id=48755)**
## Description
there are some cases I feel an urge to cleanup/redesign fontconfig API though, let me add a note here for a chance to do so in the future.
1. the API prefix isn't intuitive to find out where it's included in.
e.g. FcDirCache* in fccache.c but some is in fcdir.c. and some can see in fcfs.c, fslist.c and fcmatch.c. for FcFontSet as well.
2. some APIs is hard to imagine the functionality from the name
e.g. FcDirCacheRead() vs FcDirCacheLoad()
3. FcCacheDir() vs FcConfigGetCacheDirs()
it implies from the name it may behaves similarly but FcCacheDir() returns the font directory at this moment.
4. function doesn't take any structure as its prefix implies
e.g. FcConfigFilename() etc
5. FcConfigAppFontAddFile() and FcConfigAppFontAddDir()
that could be integrated into one and branch if it's a file or a directory?
6. In doc, FcConfigSubstitute() and FcDefaultSubstitute() are required to get FcFontMatch() and FcFontSort() working though, it's actually optional to do in the program. guess there may be a reason to do so but that looks to me like an error of API design.
may update more later...
Version: 2.9