Bug 100935 - Provide means to store the font returned
Summary: Provide means to store the font returned
Alias: None
Product: fontconfig
Classification: Unclassified
Component: fc-match (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: fontconfig-bugs
QA Contact: Behdad Esfahbod
URL: https://phab.enlightenment.org/T5453
Depends on:
Reported: 2017-05-04 18:56 UTC by William L. Thomson Jr.
Modified: 2018-08-20 21:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description William L. Thomson Jr. 2017-05-04 18:56:52 UTC
Not sure if this is applicable, or something fontconfig developers are open to inclusion. It would be really nice if fontconfig provided some means to store the font returned via a fc-match. Please excuse if duplicate.

In working with EFL UI toolkit, the one used for Enlightenment desktop. I am having great difficulties determining the default font used. The theme and other files that have font names passed to fc-match are mostly generic; Sans vs a specific Sans font. Once fontconfig matches and serves up the font. Seems there is no way to ask fontconfig what was provided. The requesting application must store this value returned via some means.

A global setting/storage would not make sense. But maybe something along the lines of Application A requested font X, but was given font Y. That is saved, so if anything asks what font application A is using; including application A itself. Fontconfig replies with application A is using font Y.

It seems most environments, GTK, QT, and others are doing this in their own way. Some are setting a specific font in config files, others in theme. Then providing API means. However if that font is missing, that would have the same issue. Font returned is other than Font requested.

This may be up to the application/UI toolkit to store the value returned from fc-match. That is fair and maybe how it was designed and intended usage. At the same time it may be beneficial to be able to re-query fontconfig to see what font was served up.

Say I am working with Progam B, I want to know what font Program A is using. If I can ask fontconfig which one was given to Program A, I can set that same for program B. One usage outside of an environment storing such. This would also allow a standard implementation of such and each would not be left up to its own means to devise such.

Thank you for your consideration of this feature request!
Comment 1 Behdad Esfahbod 2017-05-04 19:11:48 UTC
This doesn't make sense to me.
Comment 2 William L. Thomson Jr. 2017-05-04 19:22:50 UTC
I tried to explain it as clearly as I could. I am trying to determine a default/current font for a system. It seems this is not easy because of how things interact with fontconfig.

It may be outside the scope of fontconfig to retain/store the font returned to anything requesting. However that leaves the storage up to each. Some do it in configs, some in themes. But that is relying on the font to be present. If that font was not, and fontconfig returned a different one. The requester of the font must store that value returned.

I am not sure if this is fontconfigs responsibility. I am trying to get a default font, or the current font in use within Enlightenment desktop and EFL apps. From discussions on mailing list. It seems this is not possible due to fontconfig.
Comment 3 William L. Thomson Jr. 2017-05-04 19:34:32 UTC
This may help for context and reference

Topic [E-devel] Getting default/theme/system font name

Most relevant post showing getting default/system font from various envs.

Entire thread
Comment 4 William L. Thomson Jr. 2017-05-05 15:10:12 UTC
Downstream has closed this bug. For the record I think in part this is a EFL toolkit issue. However they are not receptive to any sort of change to their very strange font system. Even though I have shown host most all others allow you to get fonts from objects. If not a global default system font from theme, config, etc.

Without comment on the bug it was closed as wontfix downstream. Seems how they are handling fonts entirely is very strange and unfriendly to application development

You don't get to know what the font is that the theme has chosen because it's
abstracted. It may not even be the part name in the edj file that is the
"standard label" that determines the visible font. It may be something else.
It's abstract. You get to override or not. You don't get to peek inside the
black box.

Which I think is crazy. Objects have a font used to render them. But it seems getting such information is impossible, and they have chosen for such with some abstracted black box design.

It is very odd!
Comment 5 William L. Thomson Jr. 2017-05-05 22:01:15 UTC
Maybe better suited for mailing list. What I thinking of as a feature enhancement to fontconfig would be something as such.

Binary name maybe

Program A requests Sans font
fc-match Sans
DejaVuSans.ttf: "DejaVu Sans" "Book"

It an env/temp file, fontconfig stores
A:DejaVu Sans

Or something like that, and other programs.
A:DejaVu Sans
B:Noto Sans
C:DejaVu Sans Mono

Then if something else wants to see what fonts any of those programs, A, B, C is using, they can call
fc-current A

Which would return output like fc-match, but from the previously returned value. It may even be used by fc-match on subsequent requests from same program for same font.

Hope that makes more sense.
Comment 6 Alan Coopersmith 2017-05-05 22:12:27 UTC
That seems to assume all programs use exactly only one font, ignoring that many use multiple fonts.
Comment 7 William L. Thomson Jr. 2017-05-05 22:18:04 UTC
Valid point, such would need to be addressed as part of any implementation. That could be addressed in a few ways. Offhand

1. By the identifier used by a given program
   In simplest form it stores program name. It may store additional identifiers unique to usage in a given application. Ex:

A:editor:DejaVu Sans
A:reading:Noto Sans
A:lists:Noto Sans Mono

2. PID
   Likely not as good as 1, for same reason. Could be same process requesting multiple fonts.

Likely other methods. I think something based on #1 would likely be best but it could vary.
Comment 8 Daniel Stone 2017-05-08 14:44:21 UTC
This also assumes that each PID also has exactly one set of runtime configuration. The scope of that is not just the config file, but exactly how you feed and initialise fontconfig, e.g. with font sets.
Comment 9 William L. Thomson Jr. 2017-05-08 15:06:30 UTC
Yes I do not think PID is good. Just was coming up with an alternative to not be providing a single solution.

Likely an application specific identifier of their own choosing is best. That way they can ensure fonts, sizes, styles, etc for the various identifiers. While allowing other programs access to the same information. Once something has a font, seems other things do not really have means to find out what font its using. Say its a GTK app, that wants to mimic font of a QT, or other.

Just thoughts on a potential solution. It may not be applicable or correct in fontconfig. The idea maybe insane. Just a feature request for consideration and further thought. Definitely details to be hashed out before any implementation. Thank you for your time and consideration!
Comment 10 GitLab Migration User 2018-08-20 21:43:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/9.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.