FontManager
[Feature request] Additional category filters
Is your feature request related to a problem? Please describe. When I look for "working" fonts for my Supported ortography I would at least need to filter for both the Ortography and the searched feature, eg. Family:Script and/or Width:Condensed.
Describe the solution you'd like Category filters would be toggles:
- when I click one it is ANDed to the list of active filters
- they are listed in the top status bar/filter bar as bordered texts, buttons, similar
- right-clicking on a filter button it is removed
- left-clicking on a filter button negates the effect (gives a "!" before, sets a different color, similar)
- clicking the clear button (like an "X") removes them all
Example result:
[Family: script][Slant:normal][Supported Ortographies][!Filetype:TrueType] [<X]
Which would select Scripts with NormalSlant, having the Ortography and not being TrueType.
Possibly also combining in the collections as filters?
Describe alternatives you've considered It's not possible right now, only by manually collecting them. I see there was a simlar #43 issue which was closed by the submitter, but this way it's not possible to track the state of this feature. Also slightly reated to #316 but it's about more detailed filters.
I don't know about adding more "Categories" I feel as though we probably have too many already.
This is something that well likely enable using search in some way but that will be something to keep in mind for the next version as the current one is in maintenance mode at this point. So you unfortunately won't be seeing this anytime soon.
As far Serif/Sans categories goes if I remember correctly I don't think there was anyway to reliably classify fonts that way. We use Panose data when available to populate the Family Kind category, it's not actually set correctly in the majority of fonts anyway.
If you have some way to reliably classify font files into those categories I'm all ears.
we probably have too many already.
In what way would it be a problem, or what negative effects it would cause? Considering that there are thousands of fonts are freely available, and some people use thousands of paid fonts as well the more detailed filtering seems to be a userful feature, unless it causes some real problems. I don't readily see what problem it would cause.
I have tried to use various font manager programs which would help me to find the font I need for a given purpose, which usually mean as much attributes as possible for specific search, or usually multiple attributes for browsing (or create a font sampler sheet). Right now there are zero programs which can do that, but font-manager is the closest to the useful (since the most important filtering for me is whether the font supports my ortography, which is unusual).
won't be seeing this anytime soon.
Well, if it happens in the foreseeable future then it's still great, but if it's beyond the 10 years horizon that's tough luck.
Serif/Sans
I think it's usually in the OS/2 table sFamilyClass attribute. (Google finds refs into microsoft and various others.)
Or rather the Panose classification numbers.
Not compulsory but it's generally supported.
I think it's usually in the OS/2 table sFamilyClass attribute. (Google finds refs into microsoft and various others.)
sFamilyClass is set to something other than zero on 148 / 785 files that are currently active on my system.
If I enable a few thousand files with varying degrees of quality I can guarantee that percentage will only get worse.
In any case, we'll start collecting this value and see what happens. I'm not sold on adding another category for something with such low support. But I change my mind all the time so...
Or rather the Panose classification numbers.
We already make use of that, the Family Kind category is based on that.
I chose Panose over sFamilyClass because it seems to have a bit more support.
If I enable a few thousand files with varying degrees of quality I can guarantee that percentage will only get worse.
You mean a thousand attributes to look up? I tend to agree, yes.
In any case, we'll start collecting this value and see what happens. I'm not sold on adding another category for something with such low support. But I change my mind all the time so...
I'm trying. :wink:
Or rather the Panose classification numbers.
We already make use of that, the Family Kind category is based on that.
I chose Panose over sFamilyClass because it seems to have a bit more support.
But look how nice I am, I found a pyton font lib, learned to program in python, and collected my fonts for you (ttf only this time):
Total fonts: 1140
Missing PANOSE table: 1
Average attributes: 6.42719298245614, max attrs: 10
Has serif: 667 (58.5%) , missing serif info: 473
sFamilyClass: present 224 (19.6%), missing 916
So yes, Panose seems to be nice, except font-manager does not use all 10 panose attributes, or at least definitely not the bSerifStyle field.
No we don't. Information overload is not a good thing for most users.
Adding categories to cover all the information Panose provides would be a mess of sub-categories.
Enabling you to filter the way you want is actually a goal but it's a stretch goal and will likely not take the form you want it to.
The most likely outcome is that we'll improve search enough to allow you to get the result you want. i.e. having "sans" or "serif" in a search string takes both Panose info and sFamilyClass into account when returning results. But again, that's a stretch goal.
Also keep in mind that there is a reason our description says that it's a "simple" application and ends by stating "Font Manager is NOT a professional-grade font management solution." 😉
I'm humbled that you think I'm a professional typographer. :grin:
It's like: I need to create something, I am clueless what fonts I do have and which ones support the ortography (usually Hungarian, you know, those ODOUBLEACUTEs), try to create a sampler to be able to choose, pick, go on working. :-)
Thanks anyway, I think we have said all to be said here, I hope someday this feature will materialise and can help me.
I'm humbled you think I'm a professional programmer.
I hope it will materialize someday too.
🙂
I'm marking this as a duplicate of #285 since I think that implementing "smart" collections would also resolve this issue.