Summary: | Provide means to store the font returned | ||
---|---|---|---|
Product: | fontconfig | Reporter: | William L. Thomson Jr. <wlt-ml> |
Component: | fc-match | Assignee: | fontconfig-bugs |
Status: | RESOLVED MOVED | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | enhancement | ||
Priority: | medium | CC: | freedesktop |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
URL: | https://phab.enlightenment.org/T5453 | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
William L. Thomson Jr.
2017-05-04 18:56:52 UTC
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. https://sourceforge.net/p/enlightenment/mailman/message/35819052/ Entire thread https://sourceforge.net/p/enlightenment/mailman/enlightenment-devel/thread/20170503124800.f9dace9e7b8d27048b669e8f%40rasterman.com/#msg35818970 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. https://sourceforge.net/p/enlightenment/mailman/message/35822987/ 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 fc-current 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. 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: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. 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. |
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.