[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: a "fonts-recommended" metapackage?



On Wed, Jan 2, 2019 at 7:33 PM Fabian Greffrath <fabian@debian.org> wrote:

> Not sure if you guys would prefer going for a "core fonts" or merely
> "recommended" list.  The latter hits my recent use cases; the former could
> be suggested to the d-i team.

We are still missing some decorative fonts. I believe what people
really want apart from the standard serif/sans/mono sets is pendants to
e.g. Brush Script, Papyrus, Comic Sans (yep!) and Impact. Do we have
any recommendable alternatives for these?

Although I'm resurrecting an old thread here, this subject does seem to come up quite often.

I think one of the chief reasons a "recommended fonts" collection does not work well in practice is that "recommended"...

(a) only makes sense within a limited context -- namely, the type of document that the person will be working on. Crossed with the medium (print or web), crossed with the language and script. Recommended fonts for presentation slides, long-form booklets, and web sites are not going to be the same, even within one language, and that's not even getting into the problem that not all "web sites" look the same or need the same features from their fonts.

E.g., user:: 'the "recommended fonts" didn't give me any monospace fonts that look like they're the same size as the text fonts. Since my web site is all about discussing code snippets, this kills the recommendation for me.'


(b) comes with the baggage that recommendations are inherently personal. This is pretty self-evident, yes, but it boils down to *who* is it "recommending" the fonts here? If it's a design-by-committee decision, a lot of people may not give it more than a passing glance. Why will someone trust the recommender? Unless they have a reputation for making text look good/correct/functional, the recommendation doesn't have independent value.

For that reason, I could imagine a scenario in which individual packagers made their own recommendation metapackages -- presumably based on their area of expertise. The result being that there would be an assortment of these metapackages to choose from. Over time, that could build trust and reputation naturally. At the outset, I could perhaps dig around a bit and learn that (for example) Norbert Preining is well-versed in academic-style publishing as well as Japanese/Latin mixed-script publishing, so perhaps what he recommends fits what I will want if my project aligns with those factors. But if I'm designing posters in Sinhala, then I need to keep looking for another recommendation metapackage.

That concept kind of puts a different spin on the responsibility of the (meta)package maintainer. Open discussion as to whether enough people would want to do it, and as to whether the rest of the project would consider it a weird misuse of metapackaging. Are there other such examples in other parts of the archive? I really don't know.

Nate
--
nathan.p.willis
nwillis@glyphography.com

Reply to: