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!
This doesn't make sense to me.
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.
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.
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
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!
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
DejaVuSans.ttf: "DejaVu Sans" "Book"
It an env/temp file, fontconfig stores
Or something like that, and other programs.
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
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.
That seems to assume all programs use exactly only one font, ignoring that many use multiple fonts.
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:lists:Noto Sans Mono
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.
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.
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!
-- 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.