Topic on Talk:Design/Typography

Related discussions:

• [Design] Fonts & licenses (October 2012)
• [Design] Arial : no way (January 2013)
• Talk:Typography refresh/Archive 2#Default system fonts should be given preference over free fonts (especially on Windows)
• Talk:Typography refresh/Archive 3#Arial
• bugzilla:63512

Even before people get to the aesthetic qualities of Arial and its non-free licensing, there is a practical problem with it: It is nowhere near being a "global typeface", as this page suggests, because it covers very few writing systems: Latin, Cyrillic, Greek, Hebrew, Arabic and maybe Thai. It doesn't even cover Latin, Cyrillic and Greek well and has a lot missing characters.

Forcing Arial on languages that it doesn't support is pointless: they will change it in local CSS anyway. This includes languages of West Africa, which are written in Latin, but use many characters that Arial doesn't have.

I don't quite understand why should we specify an explicit font-family in the first place. People who read in languages for which fonts are easily available should be able to use their own preferred font (unless Wikipedia wants to create a unique identity for itself, but Arial is obviously not a font for unique identity). For people who read languages that Arial doesn't support at all it can a be a problem - millions of people still use browsers that don't support fallback fonts, and they will be forced to see squares instead of letters.

This post was posted by Siebrand, but signed as Amire80.

I also find weird the choice of Arial for Latin languages. The primary font should be a free one and then Arial can be suggested as fallback for browser compatibility. See w:Arial#Free_alternatives.

This post was posted by Qgil-WMF, but signed as Qgil.

See https://lists.wikimedia.org/mailman/listinfo/design if you'd like to give this a little more formal exposure (which I wholeheartedly support).

I thought I'd seen this discussed on a mailing list before, but it might have been "internal e-mail". Anyway, I search the archives of design and only found this post on fonts so far:

• https://lists.wikimedia.org/pipermail/design/2012-October/000191.html

Other recent news are the release of Adobe open source fonts Source Sans Pro and Source Code pro. While the industry trend is to go for a small common set of open source fonts motivated by cross-desktop and cross-browser compatibility, we can't have precisely Wikimedia going in a opposite, old school direction going for... Arial.

I will be having a presentation in 4 weeks at FOSDEM and I want to take our design guidelines as inspiration for that slide deck. I don't know what fonts will be used but I can assure you Arial or any proprietary font won't be there. Any suggestions?

This post was posted by Qgil-WMF, but signed as Qgil.

Bumping this discussion, since our default font-types are being discussed again.

The Wikimedia web UI shows content (text, images, other media), interface graphics and logos that are either free or trademarked by the WMF. For the same reason I believe we should push free fonts, defaulting to the safe "serif" / "sans-serif" for clients not having them yet and not able to use webfonts.

If someone finds some proprietary fonts are nicer that is fine: some proprietary texts and images might also be better than the ones we currently have. The Wikimedia solution is not to use proprietary alternatives but to aim improve the current free ones.

This post was posted by Qgil-WMF, but signed as Qgil.

16 months later, we've had the proof that this prediction was right about languages and non-Latin scripts not being considered enough in the decision of forcing a specific font, when several wikis have been severely disrupted for Windows users. See Edokter's point 2 at bugzilla:63512#c20.

What "severe disruption" is there?

Erwin made a claim that we didn't consider non-Latin scripts or languages with special needs that use Latin scripts. This isn't true. Even if it was, not a single new bug has been filed since we launched regarding language support. No one has been unable to read or edit Wikimedia projects that was able to before.

Before and after this update, many wikis have had to have overrides via Common or Vector CSS. This includes wikis like Persian, Chinese, Japanese, and Korean. For the worst case cited (Japanese Wikipedia) the vast majority of the issues reported are with the serif headers alone. I think if we want to try and enhance Vector's core variables to not set serif as CJK headers and other language-specific enhancements so that we don't need local overrides, that's a good thing to explore.

Before we launched this, we already acknowledged that we would need to keep working with local admins to figure out what needed to be changed. But the idea that there was some perfect utopia of language support that we violated and caused major bugs is a complete exaggeration.