Talk:Design/Typography

Jump to navigation Jump to search

About this board

RfC: [Design] Monospace font stack (source code typography): add commonly used fonts tailored for developers

1
Aron Manning (talkcontribs)

phab:T244803

Proposal

Extend the monospaced font-stack to cater to contributors who have installed one of the following modern typefaces designed for source code, some of which have specific programming ligatures.

This is a nice addition for professionals and has no effect on regular users.

  • 'Fira Code' - Webfont, monospaced font with programming ligatures.
  • 'Hack' - Webfont, a typeface designed for source code - large x-height + wide aperture + low contrast + custom zero.
  • 'Source Code Pro' - Webfont from Adobe, "has been designed to work well in coding environments".
  • 'Inconsolata' - Favored for its legibility with small font-size.
Reply to "RfC: [Design] Monospace font stack (source code typography): add commonly used fonts tailored for developers"

"Paragraph justification"

1
Sunpriat (talkcontribs)

What about image caption alignment? When should the alignment be on the left edge, and when on the center? Often the signature is centered with the center tag. Is it permissible to align the image caption in articles in the center or should it be to the left?

Reply to ""Paragraph justification""

Line spacing - footnotes

2
Summary by Volker E. (WMF)

Resolved with current way MW main themes are dealing with.

Siebrand (talkcontribs)

One important consideration in line spacing is the placement of supertext footnote references. These create uneven line spacing currently.

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

Volker E. (WMF) (talkcontribs)

This is taken care of by a specific setting in shared.css for all MediaWiki skins.

/* Prevent citations and subscripts from interfering with the line-height */
sup,
sub {
	line-height: 1;
}

Consequences of this "font stack" on Linux systems

3
Entlinkt (talkcontribs)

Most Linux distributions use the DejaVu fonts by default. Browsers tend to take the default font-family from the desktop environment and thereby achieve a consistent result between web pages in a browser and documents in other applications. I as a Linux user have been reading Wikipedia pages in DejaVu for years and am very, very happy with it.

It can be assumed that Linux distributors spend reasonable efforts to make the default fonts look good. The same cannot be assumed about "unusual" settings.

I have just tested the consequences of the proposed font stacks using the following test case:

<!DOCTYPE html>
<title>Fontstack consequences</title>
<p style='font-family: serif;'>Generic serif</p>
<p style='font-family: "Georgia", serif;'>Georgia</p>
<p style='font-family: sans-serif;'>Generic sans-serif</p>
<p style='font-family: "Helvetica Neue", "Helvetica", "Nimbus Sans L", "Arial", "Liberation Sans", sans-serif;'>Helvetica Neue and friends</p>

Results:

  • The first paragraph is rendered in DejaVu Serif, as expected.
  • The second paragraph is rendered in DejaVu Serif because Georgia is not and will not be installed on this system and Firefox doesn't find any substitute better than the default DejaVu Serif.
  • The third paragraph is rendered in DejaVu Sans, as expected.
  • The forth paragraph is rendered in the totally obscure font "TeXGyreHeros-Regular", which is neither in the stack nor my preferred desktop default font. Firefox chooses this presumably because it thinks it's in some way similar to Helvetica. It looks really, really bad, blurry, too dark and I consider this absolutely unacceptable. Note that this is what the main parts of the text will look like. I will revert this in my user.css. Others may not be able to do so.

What problem is meant to be solved by these font stacks? What has been done to verify that the desired effects and only these are achieved? What alternatives have been investigated?

Also I would like to question the explicit use of Arial in this font stack. Arial's popularity stems from it having been the default font in Microsoft products in the 1990s, but more recent Microsoft products use Calibri instead of Arial, presumably for a reason. Arial is still preferred by some because of its wide availability on old platforms like Windows XP (Calibri was first shipped with Vista), but this problem can be easily avoided by simply using font-family:sans-serif and letting the browser do the rest.

Quiddity (talkcontribs)

Well said, and explained.

In regards to "What has been done to verify [...]", I'd like to know that too. My usual method of cross-platform testing is http://browsershots.org/ (free and OSS), but I think I read somewhere that the WMF has an account with http://www.browserstack.com/ - either of those would be useful.

(Design Team: See also Steven's comments below at "Documenting reasons for current proposed typography", and my comments below that at "Notes for any potential font stack deployment")

SPage (WMF) (talkcontribs)

Entlinkt, thanks for posting your results. For what it's worth, there are many Linux users at WMF, some have investigated their font usage, and to my knowledge none have this problem.

What version of which operating system are you using? What does fc-match print for each font? I.e. fc-match "Helvetica Neue"; fc-match "Helvetica"; etc.

Some possible explanations:

  • your system is using something like Panose numbers to find closest-matching fonts
  • your Firefox is modified to pick TeXGyreHeros-Regular for one of the font names; this might be browser CSS or a plug-in
  • TeXGyreHeros-Regular claims to be Helvetica; can you please run fc-query /path/to/TexGyreHeros.pfb
  • some installer manipulated your O.S. font substitution machinery.

This font stack delivers improved appearance of MediaWiki pages. As your case shows, it is impossible to verify the desired affects are achieved in every case, due to the presence of fontconfig and other O.S.-level font substitutions, browser options, people following random "Improve your fonts!" tutorials on the web, etc. But the font stack does expresses the designers' intent: these fonts, in this ranked order, make the design appear best. A particular system's decision to substitute some other font for a well-known name in the list is often going to be a win, but sometimes not. A lot of Linux distributors spend reasonable efforts to make the many web sites specifying "Helvetica" look good.

This post was posted by SPage (WMF), but signed as S Page (WMF).

Reply to "Consequences of this "font stack" on Linux systems"

Line spacing - languages with many diacritics

1
Siebrand (talkcontribs)

Some languages use more diacritics than others. This is relevant for Latin-based languages, like Vietnamese and Min Nan, where the diacritics are far more complicated than in languages like French. And it is also relevant for Indic and Southeast Asian languages, which have a lot of signs above and below the the line. Currently in core these languages ask for larger line-height (see skins/common/shared.css).

This is an important consideration. Maybe the line spacing should just be increased for all languages. And maybe only for some languages, but the code that does it should be cleaner and more robust than it is now.

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

Reply to "Line spacing - languages with many diacritics"
Siebrand (talkcontribs)

Is there any consideration of indenting first lines of paragraphs, like in books?

Some Wikipedias use it already, for example Thai and Ossetic.

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

He7d3r (talkcontribs)
Mzajac (talkcontribs)

Indentation is good for running text in print, or other high-resolution environments.

But line breaks between paragraphs might still be the better choice in the low-res environment that most readers have in their computers, and it may be the best for the cluttered layout that many encyclopedia articles have, with their illustrations, navboxes, etc.

Vibhabamba (talkcontribs)

Hi Amir, The first line of the article carries a paragraph space or a line break.

I think this works well because the disambiguation templates, that occur in a lot of articles before the first paragraph already carry an indent, so adding another indent to the first line right below it may not help differentiate it.

I was looking at some paragraph making styles and this one site does a good job of analayzing all the combinations of marking paragraphs - http://www.thinkingwithtype.com/contents/text/

Reply to "First line indentation"
Siebrand (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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.

Siebrand (talkcontribs)
Qgil-WMF (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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.

Nemo bis (talkcontribs)

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.

Steven (WMF) (talkcontribs)

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.

Reply to "Arial?"
Siebrand (talkcontribs)

Sometimes bold and italics are called for; for example, when convention asks us to bold a key term (as in the lead of an encyclopedia article), but that key term is the title of a work that should be italicized, or a Latin binomial taxon.

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

Reply to "Bold italic"
Siebrand (talkcontribs)

It has been argued that Arial is a safe choice for the default typeface due to its availability. Using webfonts (+ Arial as fallback) could be a compatible solution that would offer more options in terms of typography.

From the technical side, I think there is already webfont support through a MediaWiki extension for displaying non-latin scripts.

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

Reply to "About the use of Webfonts"

"If a word or phrase is italicized it does not also need bolding"

6
Nemo bis (talkcontribs)

What is this sentence talking about?

Jorm (WMF) (talkcontribs)

It means you do not need two forms of emphasis. Italic is one; bold is another; bold italic is two emphasisesessesss.

Nemo bis (talkcontribs)

But where? This is surely false in Wikipedia articles, so if you attempted to proclaim it as the 11th commandment you failed.

Quiddity (talkcontribs)

I would assume that means "In the interface and documentation" only - because the article content is a different kettle of fish - but you have a good (implied but unstated) point about those 2 areas being often-distinct, and this project's description currently not clarifying that.

I think that "Shift & emphasis" is the only section on the page that requires amendment, so I'll boldly add that now.

Vibhabamba (talkcontribs)

It means that one shift is sufficient for emphasis, we don't need to bold & italicize text. Two shifts create noise which hinders from the reading experience. Vibhabamba (talk) 22:45, 4 February 2014 (UTC)

Quiddity (talkcontribs)

Just to clarify, the confusion was because: within English Wikipedia articles (and possibly/probably elsewhere), we do need and intend to use bold&italic at the same time, eg in en:Macbeth the the first word is italic because it's a title of an artwork, but is also bold because it's the article topic. (all per en:MOS:TEXT guidelines)

I think we all agree that this is fine, and the clarifications in this project-page were purely for UI and documentation elements, as per my edit. HTH.

Reply to ""If a word or phrase is italicized it does not also need bolding""