Talk:Typography refresh

Jump to: navigation, search
An archive box Archives 


Headers[edit | edit source]

Redundant bug fixes?[edit | edit source]

Changes were made in Special:Code/MediaWiki/108215, Special:Code/MediaWiki/99389, Special:Code/MediaWiki/104160, Special:Code/MediaWiki/105517 and Special:Code/MediaWiki/105521 for fixing bugs bugzilla:29405, bugzilla:30809 and bugzilla:32826. The fix for div#content h2 seems to be overridden in the beta feature (although in a good way). The line-height: 22pt; specified in the beta feature appears to be more than the line-height: 1.2em !important; specified in the original bugfix.

Not sure if the original bug fix was for vector or all skins, but it should be evaluated whether it is needed anymore.

NOTE: I've only tested this for hindi (hi) at w:hi:मुखपृष्ठ.--Siddhartha Ghai (talk) 10:00, 1 April 2014 (UTC)

Headlines on pt.wikipedia Main Page[edit | edit source]

This new typography funks up the section headlines on pt.wikipedia. [1]. Some of them get moved completely outside of the line they are supposed to be. GoEThe (talk) 11:31, 1 April 2014 (UTC)

@GoEThe: Yes, this is because the new h2 style is designed for regular content pages (including Talk, Help, etc.) so there is a bit more space above it (margin-top: 1em;). Places where there are additional local styles around an h2 might need fixing in Common.css. You can see that they already fixed this in German Wikipedia's Common.css by referring specifically to the Main Page h2's and removing the serifs and fixing the spacing. It looks like putting in styles that refer to div#artigos-destacadosHead h2 will fix this. Steven Walling (WMF) • talk 21:57, 2 April 2014 (UTC)

H4 vs H5 (and potentially H3)[edit | edit source]

Maybe I'm nuts, but shouldn't there be some difference between H4 and H5? (And more than just a stroke-width difference between H3 and the others?) LtPowers (talk) 14:18, 3 April 2014 (UTC)

They decided to make them equal size to running text to make H2 and H3 more distinguishable, as H4-H6 are rarely, if ever, used. Edokter (talk) — 15:19, 3 April 2014 (UTC)
Excuse me just a minute while I check your statement against enwiktionary-20140311-pages-meta-current.xml dump. 3970659 pages processed, 1126424 L4 to L6 found. They may be uncommon, but not rare. (Also, on en.WT L4 and L5 are semantically significant.) - Amgine (talk) 20:18, 3 April 2014 (UTC)
'Never' would be one thing, but 'rarely' is another thing entirely. Given that H4 and H5 are sometimes used, how are they to be distinguished visually? LtPowers (talk) 23:44, 3 April 2014 (UTC)
Proposal: Why not use the italic to differentiate? H4 could have the same size as H3 but in bold-italic and not in bold. H5 would stay in the actual size, H6 would be the same size as H5 but bold-italic. An example were the difference could be needed is for example the German article about Wikipedia -- 14:57, 5 April 2014 (UTC)

Article heading is complete mess now[edit | edit source]

Problems ( - screenshot with my annotations):

1. marging-bottom on #firstHeading. Why it has been introduced? It results in spacing between article header and "From Wikipedia, the free encyclopedia" (#siteSub), what looks inelegant and buggy.

2. Spacings between #contentSub and .dablnks should be equal. Now it is inconsistent.

3. And the most important thing: "  (Redirected from ...)" - #contentSub content is aligned with blank spaces (!)

I suspect that someone done it in order to align #contentSub (margin-left: 1em) with .dablinks (padding-left: 1.6em). So he just put two spaces in front of it, instead doing css tuning.

I propose the following changes:

1. Set margin-bottom on #firstHeading to 0.

div#content #firstHeading {
        margin-bottom: 0;

2a. Change spacings between #contentSub and .dablnks to be consistent (0.5em).

2b. Set margin-left on #contentSub to 1.6em (the same as .dablinks padding-left).

#contentSub, #contentSub2 {
        margin: 0.5em 0 0.5em 1.6em;

3. Now, when #contentSub margin-left and with .dablinks padding-left are the same, remove blank spaces (  ) from #contentSub content.

In my opinion after these changes it looks much more elegant and consistent:

--Piotr Jurkiewicz (talk) 00:14, 4 April 2014 (UTC)

No margin on top of h1 headers[edit | edit source]

I made an example demonstrating my issue on this page User:Stephan Kulla/ Bugreport: No margin on top of h1 headers. There you can see, that there is no margin on top of <h1> headers (I need those headers in some discussion pages of my wikibook project). Will there be a margin added in the future? Greetings Stephan Kulla (talk) 13:06, 9 April 2014 (UTC)

Strictly speaking, H1 is reserved for page titles, and we don't want a top-margin there. (It is possible, but it would have to be cancelled out for #firstHeading again.) Edokter (talk) — 13:20, 9 April 2014 (UTC)

Subscript problem[edit | edit source]

At en:Clifford module#Real Clifford algebra R3.2C1 the heading overlaps the line underneath, and than untidily the line is on top - if this is to happen surely the line should go underneath. It seems to be a combination of the subscript and the descender on the three, but it could happen with alphabetic subscripts too, and the larger size of h2 compared to what it was before (enabling 'Vector classic typography' fixes it) and compared to other skins (all also fix it).--JohnBlackburne (talk) 02:09, 18 April 2014 (UTC)

It now seems ok, with the 3 no longer descending and the font looking a bit smaller. I can't find any note on what's changed, in the last 24 hours, here or on en.wp.--JohnBlackburne (talk) 01:11, 19 April 2014 (UTC)
Ah, worked it out. It was applying a fix a moment after loading: for an instant I could see the old broken behaviour. Then realised I had enabled 'Download fonts when needed' in the last 24 hours. With that on, and presumably Linux Libertine, it's OK. With that off and I think Georgia (which looks better to me) it's broken.--JohnBlackburne (talk) 01:16, 19 April 2014 (UTC)

OpenType[edit | edit source]

Hi everybody. I have trouble visualizing the Linux Libertine font in Mac OS. It happens with font with OTF extension, the TTF works well. Maybe the OTF is not recognized because it is called Linux Libertine O. Can this be fixed? --Gusama Romero (talk) 03:00, 4 <april> 2014 (UTC)

That’s exactly the reason. It could be easily fixed: font-family: "Linux Libertine", "Linux Libertine G", "Linux Libertine O", Georgia, Times, serif. -- 09:39, 18 April 2014 (UTC)

Languages problems[edit | edit source]

See also #Only Latin script is targeted

Can some more free fonts in Korean also can selective?[edit | edit source]

Hello. I'm editor on Korean WP, and I saw your notice on our villiage pump.

As for Korean. There is good fonts for korean, which is distributed by Free copyright licences. For example, Nanum fonts(Nanum means 'share' in Korean), which is distributed by Open Font Licence 1.1. And these fonts shows better legibility than normal fonts like Gulim and Dotum. And Un fonts also serves in Open licences, but I think these fonts do not have good legibilities.

If this refresh project supports multiple selection of fonts, How's about Include Nanum fonts and some more open fonts in Wikimedia projects when using Korean? - Galadrien (talk) 12:42, 1 April 2014 (UTC)

Hi Galadrien. I think it would be fine to write in Korean Wikipedia Common.css to refer to a different open source font. But as the FAQ notes, we're not actually having users download new fonts, we're only telling their browsers which fonts to use, if they already have it. So unless most readers or editors on Korean Wikipedia would already have the font on their system, there may not be much point in changing it. As a side note, I am also curious: do you think the serif font for page titles and section headers is okay in Korean? I know non-Latin scripts may look different with serifs. Steven Walling (WMF) • talk 22:07, 2 April 2014 (UTC)

Um.. It maybe good, but At this point, em-size of English font and Korean font is different- so you have to think how to make balance for English and numeral decender and Korean baseline.

And, especially, printed materials in South Korea(And CJK printing culture also) do not uses serif fonts for main subject- they usually use san-serif as subject, then use serif for main contents. So you can make think about make changes for CJK languages. - Galadrien (talk) 02:52, 4 <april> 2014 (UTC)

I uploaded the sample of 'problems' in my wiki. Please check the circles especially. - Galadrien (talk) 03:05, 4 <april> 2014 (UTC)

위키백과:사랑방 (기술)/2014년 4월#문서 제목 서체에 대해 also talking about this problems. - Galadrien (talk) 03:16, 4 <april> 2014 (UTC)

opinions from pl-wikt[edit | edit source]

See also

Translated feedback from the Polish Wiktionary's Village Pump (BTW Polish Wiktionary has reverted the changes, so that the problems are not observable there now):

Typographic nightmare! Some amateur serif font in the header with a chaotic kerning and spacing. Especially the bold font in the text is badly displayed on the monitor:

  • e, s and a lost themselves in the horizontal elements
  • Vertical element f is displayed thinner than the other ones,
  • The colon and parenthesis look as if they were larger than the rest of the text,
  • All Polish diacritical marks look like the amateur character modification in the early 90s when the Polish computer science was in its youth,
  • Poor kerning, which almost glued some characters, such as •••,
  • Capital letters B, F and J look like from a different font,
  • Kerning in text is disastrous, because it gives the impression as if letters were thicker sometimes and thinner in other places.

And this widened font, which is not more legible, but it causes expansion of the inflection tables in the text. Fatal amateurism. I understand that the Wiki is a community project, but it would better consult such changes with someone who has a little sense of aesthetics and typography?

Another examples of amateurism of the selected font :

  • W) ← parenthesis is placed lower then letters
  • zn ← the letter "z" is narrower than the "n" and the put together they look like from completely different fonts (dyskusja) 21:33, 1 kwi 2014 (CEST)

Please communicate to them, that the change is awful and please restore the former style. Marek Mazurkiewicz (dyskusja) 1:02, 4 April 2014 (UTC)

Thank you for acting as ambassadors on behalf of your community. πr2 (tc) 01:39, 4 April 2014 (UTC)
You are right in many points. I noticed the bold e and a looks bad in Chrome. If I change the size to 1em, it looks better. So it's a case of bad hinting / kerning, IMHO. Same with "zn", if you zoom or set size to 1em it looks better. Agree on parentheses, too. I do like the quirky "J" in Arimo/Liberation Sans. -- 22:46, 4 April 2014 (UTC)

Height/width issue & Russian wiki issues (ST vs CTT, СГT, 1234567890)[edit | edit source]

Cycillic letter rendering issue

There is something very bad with new font: it changes height/width ratio of chracters (or text block?) from one size to another. My calculations show 13 % ratio differences for my usual height in Chrome (10, I assume) and two zoom-clicks higher (12, I assume). Subjectively, usual font look much wider than before, 11 is ok, but 12 is narrow.

Also there are worse problems for cyrillic fonts. In 10 bold italic (sometimes italic only), character "и" is rendered one or two pixels shorter than others (may be local browser/OS problem), check: абвпипабв, абвпипабв; and this new font is generally bad for cyrrilic; and tables (and all beautiful templates since they depend on tables) is sometimes have no enough space for one line text representaion (was fine before changes). *panic mode on* IT'S ALL RUINED!!!!!!!!*panic mode off* --Igel B TyMaHe (talk) 08:57, 4 April 2014 (UTC)

PS. Oh, my eyes! Did you ever check that?!
That's Georgia; it has "old-style" numerals. That's just how the font looks. Edokter (talk) — 12:44, 4 April 2014 (UTC)
Igel B TyMaHe, please file bugs or the issue will be forgotten: one for абвпипабв and, optionally, one for height. Remember Typography refresh/Font choice/Test#How to inspect and include OS, browser, locally installed fonts, screenshots. --Nemo 07:46, 11 April 2014 (UTC)

Inconsistent font heights with Georgia for CJK[edit | edit source]

inconsistent font heights with Georgia and Japanese typeface

Can Georgia be dropped for CJK? In CJK typography, each character in a line is expected to be bounded by a virtual square. [2] Latin numerals are widely used in CJK documents (it's even a norm in Japanese Wikipedia), and Georgia's presentation of Latin numerals with inconsistent height breaks this rule and gives unorthodox appearance there. Linux Libertine seems to be acceptable in this regard, but most Windows users see it fallbacked to Georgia. I'm aware that each wiki can override it, but I thought this issue has some universality. Speaking personally, using serif (or Ming/Mincho) for headings in Japanese seems ok to me. See also #Can some more free fonts in Korean also can selective?. whym (talk) 00:59, 5 April 2014 (UTC)

See #Article title and sections - the differing heights for numbers are a feature of the Georgia typeface, and hence look equally odd in all languages/combinations! –Quiddity (talk) 03:51, 5 <april> 2014 (UTC)
Thanks for the link. It seems that at least capital Latin letters are comparable to CJK text in regard to the expectation of consistent height. whym (talk) 04:42, 5 April 2014 (UTC)
There is a way to force Georgia to use lining ('normal') numbers by using the following CSS:
.digits {
    -moz-font-feature-settings: "kern" 0, "lnum", "tnum";
    -webkit-font-feature-settings: "kern" 0, "lnum", "tnum";
    font-feature-settings: "kern" 0, "lnum", "tnum";
Works on the newest browsers, so it's not perfect. If you do not want old-style numbers, you may simply have to change the font in Common.css. Edokter (talk) — 11:08, 5 April 2014 (UTC)
whym, can you please report this specific issue in bugzilla? There are too many issues and nobody is triaging bugs reported on this page. --Nemo 07:38, 11 April 2014 (UTC)

Article title and sections[edit | edit source]

Please look at 987654321 (I know it's red, just click). Numbers are unaligned, some up and some down. It's impossible to read them. Please use another font. --NaBUru38 (talk) 10:31, 4 April 2014 (UTC)

Not just unaligned, the 1 and 2 are distinctly different sized from the others. Horrible font form a readability standpoint. A comparison (Win7, FF28): -- 11:39, 4 April 2014 (UTC)

1234567890[edit | edit source]

See also [3]

different heights of numbers--Sasha Krotov (talk) 20:36, 4 April 2014 (UTC)

Compare to File:NewTypDesignForRussianWikipedia.jpg --Vegen451 (talk) 10:21, 4 April 2014 (UTC)

This is a feature of the en:Georgia (typeface), and I agree it's quite odd. It looks particularly strange for years in article titles, eg en:1984–85 NHL season, or mathematics related topics, eg en:142857 (number). –Quiddity (talk) 21:20, 4 April 2014 (UTC)

These are so-called en:Text figures. Georgia is designed as a book type, and these numerals make sense there. It's true that people aren't used to these on the web or in headlines. -- 21:59, 4 April 2014 (UTC)
And that's only one of the reasons Georgia was such a terrible choice of H1 H2 font in the recent typography disaster —WinTakeAll (talk) 03:44, 5 <april> 2014 (UTC)
Old-style numbers is good for book cover, allowable for plain text but look weird in headers. It's must be changed.--Tucvbif (talk) 12:09, 6 April 2014 (UTC)

Hebrew fonts[edit | edit source]

Many editors in the Hebrew Wikipedia don't seem to be happy of the change and have opted for reverting it.

Someone wrote a gadget that sets fonts back to sans-serif and reverts the change of font sizes. It is not the default, but seems to be welcomed (discussion in hewiki - Hebrew).

I'm not an expert of typography, but right now the serif fonts used don't look good in Hebrew: Georgia does not seem to have a Hebrew script, and the Hebrew scripts of both Linux Libertine (on my Linux system) and Times New Roman (on Windows systems) don't look good enough. I'm playing now with David (availble on most Hebrew Windows systems. On Linux: available from the Culmus fonts, IIRC). But naturally it does not have the coverage of Linux Libertine and Times New Roman. Tzafrir (talk) 16:15, 4 April 2014 (UTC)

the new design doesn't work for Hebrew. i don't think u can treat such different set of signs (languages) the same. if u check the new Hebrew sets of titles u'll see it. level 3 title is not only ugly (and clearly doesn't merge with the shape and flow of the other titles) but is much more dominant and outstanding then the higher ones - so no aesthetics and bad representation of hierarchy = bad GUI. it seems each language should have its own design or localisation. at least change Hebrew level 3 font design. tnx Dalilonim (talk) 19:56, 4 April 2014 (UTC)
Tzafrir & Dalilonim, going to the page that you linked to and not seeing any readability or rendering issues. Can you post a screen shot of the issue since we can't reproduce it? Thanks!Jaredzimmerman (WMF) (talk) 23:50, 4 April 2014 (UTC)
I'll note that I'm personally mostly happy with the change, with the sole exception of the title font. Hanay complained about the same issue below. I use a Linux system and therefore cannot produce a screenshot of Times New Roman on Windows. My system is Debian Wheezy (7.0) running w:IceWeasel 24. In hewiki I set the title font to David (provided on my system by the Culmus package, but is also a high quality Hebrew font on Windows system. It also happens to be the font used for the logo of the hewiki) and I'm happy with it. Here is the default and with David font. Tzafrir (talk) 12:50, 5 April 2014 (UTC)
i uploaded several screenshots to show differences between the verses (not the best quality but hopefully good enough). one is the new and the other is with the gadget (if the gadget undo all changes we can see that as the old version). [4] [5] and the rest in the gallery below.
i think they cover the main issues. font design, size and proportion change in zooming, titles.. Dalilonim (talk) 13:39, 5 April 2014 (UTC)
Note that Dalilonim's first pair is regarding the daily quote from the main page. That quote (and some other templates) use the CSS style hebrewQuote (IIRC), which sets the font to David. This is not related to the recent changes. The gadget she refers to seems to explicitly set the font to sans, overriding the usage of David in those templates (or maybe I miss something and the recent changes did change this font to some people?) Tzafrir (talk) 17:21, 5 April 2014 (UTC)
i dono how it affected each user, but i see many differences. as i experience it, its not unified enough, titles font changes and breaks the general pleasantness, clarity of text has been lost (as with the quotes and in general - i think this aspect is really important cause we donot serve only 12:12 sight people. as 'boring' as the previous font might look, it is more clear and readable), with the change of zoom there's a total lost of proportion. and in 'normal' zoom the content text is too large and catches too much space. maybe there r more things that need improvement.
a general question, isn't that something hebrew wiki needs to solve? after all we r the hebrew readers/writers. there r general changes that can be made in the design, but in some areas its the specific language signs that need to be considered. hebrew and english font might bare the same name (type), and share some decorative qualities but beside that they r totaly different and have plenty of qualities they'll never share... Dalilonim (talk) 22:18, 5 April 2014 (UTC)

The new font in Hebrew: Times New Roman[edit | edit source]

The community in Hebrew wiki is very un happy with the new font Times New Roman. It looks not good in Hebrew. I would like to know who choose this font? Did an Hebrew reader was a part of the team who made the decision? and what is need to be done to go back to the old font?

In Hebrew wiki we already have a gadget that take us back to the old design. Thanks Hanay (talk) 04:37, 5 April 2014 (UTC)

As a Hebrew-wikipedian I agree with Hanay. The Times New Roman font doesn't look nice in Hebrew. The new design also caused several other problems, as some wikipedians have reported in our village pump. We will really appreciate if if the new changes will be cancelled. Mr._W
Times New Roman should not be displayed for any users. Both Windows and Mac users have Georgia, which is the specified font. For Linux, they should be getting Nimbus Roman No9 L. Steven Walling (WMF) • talk 02:03, 8 April 2014 (UTC)
hello Steven Walling (WMF), do u know who coordinates the topic in hebrew wiki? Dalilonim (talk) 03:45, 8 April 2014 (UTC)
Dalilonim and Hanay, you need to file a bug or the issue will be forgotten. Remember Typography refresh/Font choice/Test#How to inspect and include OS, browser, locally installed fonts, screenshots. One separate bug should be filed for each combination and for each issue. --Nemo 07:42, 11 April 2014 (UTC)
tnx Nemo i filed them :) Dalilonim (talk) 01:43, 12 April 2014 (UTC)

identified bugs[edit | edit source]

for now we identified few bugs:

  1. Times New Roman font not suppose to appear at all, but exist in the CSS definition of family font for H2;
  2. font does not much the size defined in new design;
  3. when zooming some of the properties of different texts change and the changes r not proportional - text with different function do not preserve their place in hierarchy (for example h5 becomes smaller then content text);

i uploaded more accurate images for bug reports:

About troubles include IE's rendering error in Japanese Wikipedia[edit | edit source]

Hello. This new font setting bring bad situation in Japanese Wikipedia. (Discussion )

  1. Old versioned Internet Explorer (IE8, IE9, IE10) render wrong. (mixed serif and san-serif at random, mixed Japanese letters and Korean letters at random) (Screenshot : [6])
  2. We normally use Asian serif fonts (Mincho) for main contents and san-serif (Gothic) for title letters, or often use the same font for both. Because new typography is reversed, readability for people in some Asian country is lost.
  3. Old style numerals of Georgia font damages Japanese readability. Because the baseline of all Japanese letters are straight, Almost Japanese unfamiliar with Georgia font, therefore regard texts include Japanese original letters and Georgia's numericals as incorrect text lendering. (screenshot : [7])
  4. Not only Wikipedia, but also other Wiki sites, have these same problems. And perhaps many Asian countries, too (in these countries, 2byte letter fonts, such as Chinese Kanji, Korean Kanji and Hangul, Japanese Kanji and Kana and so on, are used with 1byte letter fonts). We are going to introduce new local css in Japanese Wikipedia, but this way for only each community isn't a efficient solution against these problems.

Especially, wrong serif rendering on IE is very serious. Please rollback to previous font-family setting (all elements "san-serif"), as soon as possible.

However, some of us have a high opinion of new typograpy except but a few problems relating to "font-family" setting. And We hope for the best solution to achieve the requirements, high readability, consistency, availability and accessibility for all people.

We are collecting more opinions and reports include petition signatures from Jpapanese Wikipedia editors about this matter. Thank you. --ディー・エム (talk) 05:57, 6 April 2014 (UTC)

Update: The IE issue (#1 above) caused by a known bug of the browser (screenshot) was considered to affect a significant portion of the users, and the jawiki community resorted to cancel the change of the font-family by editing ja:MediaWiki:Vector.css (diff). In the longer term, I would hope for a localisation system for the font stack on or in the repository, because this and a few other problems noted above seem to be language-dependent rather than community-dependent. whym (talk) 22:05, 7 April 2014 (UTC)
whym, can you please report this specific issue in bugzilla? There are too many issues and nobody is triaging bugs reported on this page. --Nemo 07:38, 11 April 2014 (UTC)
Submitted bugzilla:63817 for #1 above. Other points are not included in the bug report, and are in discussion over at Japanese Wikipedia's VP mentioned above. whym (talk) 13:26, 11 April 2014 (UTC)

French portal list[edit | edit source]

Hi, better to look at this French page than a long explanation : --Salix (talk) 10:31, 4 April 2014 (UTC)

An admin needs to add margin-top:0; to all H2 headers on that page. Edokter (talk) — 12:44, 4 April 2014 (UTC)
I fixed the local template. Not sure why there is a bug for this. Edokter (talk) — 13:35, 4 April 2014 (UTC)
Thanks Edokter. Now it looks ok for me. --Salix (talk) 17:06, 4 April 2014 (UTC)
Oops Edokter, some users are still complaining, it's no fixed on wordwrap for small screens : [8]. Any idea ? --Salix (talk) 18:59, 4 April 2014 (UTC)
Salix, Not much I can do about that... Make the font smaller, or make it sans-serif again (as it was designed for that). Tell me if you want that. Edokter (talk) — 19:38, 4 April 2014 (UTC)
Edokter Because of 8 inches screen users complaining, could you please come back to the previous font for this kind of title ? --Salix (talk) 20:54, 4 April 2014 (UTC)
The headers now use sans-serif again. I hope that fixes it. Edokter (talk) — 21:10, 4 April 2014 (UTC)
Edokter Thanks. I'm waiting for a feed back from my small screen users, but it's getting late in France... --Salix (talk) 21:26, 4 April 2014 (UTC)
Edokter According to them, it seems to be better, but again a little bit too large compared to the original state. --Salix (talk) 22:43, 4 April 2014 (UTC)
(←) That is because the overall font size is bigger now. Other templates may have the same problem. I'll let the local template experts handle this further. Edokter (talk) — 23:50, 4 April 2014 (UTC)

Kerning errors e.g. "ама"[edit | edit source]


Formal Beta status (or a dashboard)[edit | edit source]

This feature was released to all wikis. It means it was turned on. But I don't find it useful to remove it from beta tab then, as it has nice big fat buttons where people can provide feedback, as many of them would like to do after you turn it on. Gryllida 11:34, 4 April 2014 (UTC)

Recently beta[edit | edit source]

If you don't consider it beta, please add a list of 'recently beta' features to the beta tab, with a note that they were deployed. Gryllida 11:34, 4 April 2014 (UTC)

Show Deploy time/plan in the beta tab[edit | edit source]

For each of the beta features, please also show the deploy plan for current wiki, if it exists. Gryllida 11:34, 4 April 2014 (UTC)

Mistakenly posted to the general Beta Features talk page

Please read this note and participate, by filing bugs in bugzilla and setting them a reasonable priority. Thanks. Gryllida 11:36, 4 April 2014 (UTC)

Middle dot with Liberation Sans[edit | edit source]

The middle dot disapears with Liberation Sans in italics. This affects specially in Catalan language as it is used in the group "l·l" (italics l·l). For example, at w:Interpunct#Catalan I see "e.g. cel la" instead of "e.g. cel·la". --Vriullop (talk) 14:29, 4 April 2014 (UTC)

Reported in bugzilla.redhat. --Vriullop (talk) 16:36, 4 April 2014 (UTC)

How to determine which Font are being used in your Browser?[edit | edit source]

And what about IE, Opera, Safari, and other minor browsers?! -- Jokes_Free4Me (talk) 01:01, 7 April 2014 (UTC)
I added IE 11 and Opera. It's pretty similar. But IE seems to show only the stack, not which font is really used. -- 15:44, 7 April 2014 (UTC)
TY for that. Fortunately, the alternative of "copy-paste into a WYSIWYG text-editor" appears to work okay on identifying which font was actually used. Now there's one thing i'm not sure how to do: inspecting browsers on the Android mobile OS... -- Jokes_Free4Me (talk) 18:25, 7 April 2014 (UTC)

Where to download Fonts?[edit | edit source]

Another technical approach[edit | edit source]

It is clear there are some unwanted side effects. This is a result of trying to target all platforms in a single font stack. I really wish there was some mechanism where we could provide each platform (OS) with their own fontstack, so we could avoid fonts ending up being displayed on a system those fonts were never intended for. Does LESS, ULS, ResourceLoader or any ohter component have any such mechanism? Edokter (talk) — 19:43, 4 April 2014 (UTC)

That would be very cool. But if it's not possible or feasible, I would vote for a return of boring Arial to the body text. There are too many problems that can't be swept under the rug (especially the bad looks without anti-aliasing and bad (Polish) diacritics). I would put the text at 1em, and have a line-height of 1.5em. I believe we can't have a font that fails without anti-aliasing. Right now, I believe there are still too many people who don't use anti-aliasing, for any reason. I checked a number of fonts, and it's no surprise that only MS own core fonts still look good if cleartype is turned off... So if it needs to be something else than Arial, Trebuchet and Georgia are also well distributed on Macs. Georgia looks good in long texts, even at small sizes! For Linux, we could keep Arimo / Liberation Sans and Libertine / Lib Serif / Tinos in the stack. -- 23:05, 4 April 2014 (UTC)

Just another idea: Can CSS be loaded after a cookie has been checked? If that's possible, we could have a style-switching button or menu. It would set a cookie so that the choice gets remembered. -- 20:40, 6 April 2014 (UTC)

non-readable[edit | edit source]

Please return to previos typography, the new one is non-redable --Vegen451 (talk) 07:31, 4 April 2014 (UTC)

Please explain the readability issues you face? Inlcluding your OS and Browser would help us address your issues. Thanks Vibhabamba (talk) 23:37, 4 April 2014 (UTC)

Line height bug?[edit | edit source]

Line-height seems to be a mess, starting with 1.6em for div#content, then 1.5em for #bodyContent and ending in 'inherit' for 'div@content p'. Has this been thought through? Edokter (talk) — 14:01, 15 March 2014 (UTC)

There is a bug out for this and we are looking into it. Ideally the line height is a bit more open. A core setting over-rides the line height change right now. Vibhabamba (talk) 19:11, 28 March 2014 (UTC)
I see the problem now; the 1.6em lineheight shoud be set for #bodyContent, not div#content. Edokter (talk) — 20:15, 3 April 2014 (UTC)
Thank you for taking the time to scrub this. Can you include screenshots of what you are seeing. Vibhabamba (talk) 23:43, 4 April 2014 (UTC)
It wouldn't show much. Suffice to say, basic body line-height is still 1.5em and not the intended 1.6em. Edokter (talk) — 23:53, 4 April 2014 (UTC)
(talk) We can file a bug for this. Vibhabamba (talk) 00:48, 5 April 2014 (UTC)
I thought you said there was already a bug for this. Do you have a bug#? Never mind, I opened a bug and submitted a patch. Edokter (talk) — 15:51, 9 April 2014 (UTC)

My eyes are bleeding[edit | edit source]

Seriously, this new font is terrible. I can barely get through one sentence of an article without my eyes getting confused. The old font was just fine the way it was, but this new one is simply painful, nigh unreadable. Is there any way for me to revert to the old Wikipedia font? --Samuel Peoples (talk) 00:28, 5 April 2014 (UTC)

Please explain the readability issues you face? Including your OS and Browser would help us address your issues. Thanks Vibhabamba (talk) 00:43, 5 April 2014 (UTC)

Actually, as of an hour ago, the font seems to have changed again on Wikipedia. It's still different from the old font, but it's now larger than it was an hour or so ago, and seems more readable. --Samuel Peoples (talk) 02:27, 5 <april> 2014 (UTC)
I just noticed this and I want to restore the new type. However it is not appearing in my beta preferences. This MediaWiki page is displaying with the new type and I would like to make Wikipedia pages do the same as I love the changes. - User:Shiftchange
As it is now, the normal text is all in bold in various browsers on Windows 7 and 8 and in any Wikipedia by country I checked.
Wiki20140405 ie.png Wiki20140405 gc.png Wiki20140405 ff.png
I do not understand how such a major change could be made without regard for how it will look on different browsers and operating systems. It basically messed up every country's Wikipedia on the planet. Cush (talk) 19:46, 5 April 2014 (UTC)

How do we know how many people opt out?[edit | edit source]

There is some considerable feedback from the community. I personally don't like this change at all, but let's be constructive: how do we know how many people opted out of this change? Couldn't this be made a "Beta feature" on by default (if you insist), but it is possible to turn if off and quantify (say, among most recently active contibutors)?  « Saper // talk »  16:12, 5 April 2014 (UTC)

We can measure gadget use at en:Wikipedia:Database reports/User preferences, but it is not update very often. Edokter (talk) — 17:38, 5 April 2014 (UTC)
Thanks. This works only for those using the gadget (now available on enwiki and others), but not if anybody applied manual workaround as presented on top of this page.  « Saper // talk »  21:53, 5 April 2014 (UTC)
We do have live gadget data, see tools:~liangent/gadget_usage/enwiki_p/. For a complete measure one should "grep" the dumps for css user pages and to count how many new monobook users we got... We can't know how many tell browsers to ignore site-specific font settings though. --Nemo 22:21, 6 April 2014 (UTC)
Was 160 there, now 195. --Nemo 13:32, 9 April 2014 (UTC)

Dyslexie & wrong use of serif/sansserif[edit | edit source]

Two comments:

  1. Updating fonts could be a great opportunity to choose for use of special dyslexie fonts, which are more easily readable for all people. These fonts are designed for ease of use and look great in print as well as on screen.
  2. A mix of serif (in headings) and sans serif (in body and smaller headings) is bad typography, as most experts on layout and typography will tell you.

Just my 2 cents. Tjako (talk) 21:23, 5 April 2014 (UTC)

I can only agree that the mix of serif/sanserif fonts is a bad idea and probably the most important reason for people to opt out from this otherwise quite sane change (say I who use Monobook most of the time). /Esquilo (talk) 16:20, 6 April 2014 (UTC)

"BUY NOW BUY NOW" hints a ploy. Seriously, the dyslexie font wants money and the font is hard to read, worse than Arimo.

Arial and verdana are free and much much better to read.

Freedom and freeness.

It's already possible to use a free/open font called "OpenDyslexic" on Wikipedia. Go to a Wikipedia article (e.g. w:Elephant), go to the left side and scroll down to the languages list. Right next to the top of the "languages" there is a gear icon. If you select the gear icon, there will be two tabs at the top of a window that pops up. Select "Fonts", and then select "Download fonts when needed". This will create a drop-down menu for fonts. There should be at least two options: System font and OpenDyslexic. Then click the "apply" button. πr2 (tc) 23:53, 6 April 2014 (UTC)

Why not use browser defaults?[edit | edit source]

Would Wikipedia be any worse if the font was "serif" or "sans_serif"? It would lead to some variation depending on the browser defaults. But I assume most browsers use a font that is well readable as default. Could there be problems with non-latin scripts? A browser in China or Korea would have a sensible default font for their language -- or am I mistaken?
So we would not have to worry about those things at all. The CSS would only need to define sensible sizes and spacings. These should also be no problem if the units are "em". A line-height of 1.5 or 1.6em would always look good. A margin of 2em would always be well visible.

Is there a list of factory defaults for sans_serif and serif in different browsers? On Win7 most browsers seems to have Arial/Times New Roman. Which is OK, readability-wise and also when it comes to Unicode coverage. And if a user hates these two, it's easy to change for everyone. Sounds like a win-win to me!
Btw, if you want to try fonts quickly without starting the web-inspector tools, the "Soma FontFriend" bookmarklet is helpful. -- 21:13, 6 April 2014 (UTC)

Yes, we have a list. Before this change, Vector fonts were like this: Typography refresh/Font choice#Current situation. Conclusion of public beta testing has always been that just "sans-serif" (i.e. browser defaults) should be used, see Typography_refresh/Font_choice/Test#Pre-conclusions. --Nemo 22:17, 6 April 2014 (UTC)

Different size of text from one browser to another...[edit | edit source]

While trying to fill in some gaps of Typography refresh/Font choice/Test, i've noticed something... odd, IMO. Safari uses a smaller font than Internet Explorer 8, (at least for the sans-serif and monospace test cases) even though they both report the CSS as being "2 em". See comparison image on tinypic. On the other hand, i just tried the same procedure on IE9, and while on screen the sans-serif cases 2 and 3 looked the same, and very different from the 1st case, the copy-pasted versions (into MS Word) had used the same Arial font for the 1 and 2 cases instead, leaving Helvetica on only the 3rd case (and all 3 lines looked very similar) -- guess i should make an updated version comparing all three browsers. So now i'm not so sure about the suggestion of "simply copy/paste the text into your WYSIWYG/rich text editor of choice"... I would ask for other people's suggestions on a better such choice of editor, but i've also tried OpenOffice's Writer and it didn't even accept the Clipboard contents. :-| So, yes, i'm interested to find alternatives, but even if they're better for most tasks i can't be sure they will work for this particular issue, of determining on-screen fonts.

Anyway, after so much context given above (since i'm not really sure what i should ask about this situation), i'm wondering whether the fact that the same font with the same style can appear differently based on browser choice, was considered when designing a "one-size fits all" font stack? -- Jokes_Free4Me (talk) 19:04, 7 April 2014 (UTC)

I know that you can set a minimum font size in Opera and FF and probably most browsers. So it may be that some browsers have a different default setting already, or that a user has changed it. But as far as I understand it, em is always relative to the default (html? or browser-default?) font size. 1 em is the width of the default-sized "M". An emspace is the same width as an "M", 2em is the width of "MM" etc. If the browser says a default M is 10px wide, em=10px. If it's 16px, then em=16px. Maybe there is an explanation of the technical details on W3C?
About the copy-paste thing, I'd do that with Write, but I wouldn't be surprised if it changes something. That method is really a very last resort. Maybe it would be better to zoom the browser window very much bigger, and then use an rich text editor to compare the possible fonts. Arial and Helvetica can be told apart quite clearly (see ), but Arimo and Liberation Sans are practically the same fonts.-- 21:33, 7 April 2014 (UTC)

Evaluation[edit | edit source]

Cross-posted on Bugzilla:63512#c20

I was not enthausiastic in the beginning, but was willing to give it a try. But now that it has gone live, there are simply too many issues that were not anticipated (even by me). I am going to list all the issues:

Free fonts render bad on Windows (at least without font smoothing)[edit | edit source]

Even though font smooting has been the default since Vista, I was suprised to see how many people have it disabled (for whatever reason). I don't know how many exactly, but the response suggests it is not a negligable part of our readers.

Only fonts made by/for Microsoft have been hinted for screens without font smoothing or ClearType. Other FOSS fonts are hinted but only for scenarios with font smoothing enabled, not for 'grid display' (pixel display hinting).

But not only free font are a problem; There are very bad copies of Helvetica floating around (HP printer drivers for example) that display atrocious with or without smooting. That means carrying Helvitica in the font stack also carries the risk of bad display.

Only Latin script is targeted[edit | edit source]

See also #Languages problems

That means only languages based on Latin, and perhaps Cyrillic, could benefit from the typography refresh. Other scripts, most notably, Hebrew, CJK, Hindi, Arabic and all other non-Latin based scripts that usually depend on ohter fonts such as David, Batang and MS Gothic on Windows for proper display, have *never* been considered. This is perhaps the largest oversight of all.

In conclusion, it is impossible to target *all* platforms *and* scripts in one single font stack. And I believe we should no longer try. There is not going to be a 'solution'; we are not a "single language" website, where typography has much more freedon because it only has to deal with one script or language.

I am now convinced that a single font stack for a website, or more specifically, the software running that website, that has to deal with the *most* languages and scripts then *any* other website, is simply not possible.

Each project should have the freedom of choice to decide on their own font stacks to suit their needs as best they can. From the point of view from MediaWiki, that means it should not force any specific font at all.

Has this been for nothing? I don't think so, because we could learn a lot from this and perhaps work on other solutions to help each project with their typography. But in its own right, the "Typograhy refresh" has failed as an practical solution. Edokter (talk) — 20:33, 7 April 2014 (UTC)

Thank you for this summary, very well done. I agree completely.
My personal summary would be: First I noticed something different with the fonts, they looked good, I liked it. Out of curiosity I looked for any announcements about the changes, and found the signpost and the pages here. Then I read about people's complaints and did some tests and saw that they were not exaggerating. So even if on my system everything was fine, a change that brought huge problems to others was not a good idea.
If Mediawiki has a default font, it should be the lowest common denominator, "sans_serif" (because the other option "serif" often means "Times New Roman", and that needs to be larger to be well readable on a screen).
It would be great if MediaWiki could offer help to all the regional wikis on how to set up a good solution for their typography. Typographic finesse is also in the sizes and relations of elements. That's what can be tweaked independently from the display font. -- 21:51, 7 April 2014 (UTC)
Agreed with Edokter., we've had one positive experience in this area, namely ULS. For ULS, a font is added for a language only when requested, beta tested and confirmed by a language community, so that no font is added that disrupts any language severely. This is a lot of work however and I'm sure it's not going to be duplicated here just for a "typography refresh", so we'll certainly be forced to use the generic "serif" and "sans-serif" in core. We already have a patch: gerrit:124475. --Nemo 07:07, 8 April 2014 (UTC)

Update on the body font settings[edit | edit source]

Hi everyone. I just wanted to let you know that we've updated the body text font settings. Liberation Sans and Arimo are now removed, and the font stack is "Helvetica Neue, Helvetica, Arial, sans-serif". We removed them due to bug 63512, where Windows users (especially those without font smoothing turned on) had significant problems with readability with Liberation Sans or Arimo. Thanks for your understanding and patience so far, as we've worked to address any issues after the new release. Please do let me know if you find the experience improved now, or if you encounter any new issues. Steven Walling (WMF) • talk 02:04, 8 April 2014 (UTC)

You are an idiot. 23:27, 18 April 2014 (UTC)

kerning (Linux/firefox)[edit | edit source]

For what its worth, here's what I see:


In particular note at the kerning problems on small text (Particularly noticeable for example between the l and the a in disclaimers in the footer). I'm also not a fan of the very narrow stroke width on serif headings. Less objectively, I find it harder on the eyes than what my browser chooses by itself, and quite simply just not as "pretty" as the previous version. As far as I can tell, firefox is chosing the fonts "Helvetica" and "Times", which possibly map to "Nimbus Sans L" and "Nimbus Roman No9 L" respectively. Bawolff (talk) 08:14, 8 April 2014 (UTC)

A screenshot showing the kerning problems even worse:


I actually measured the spaces in the caption. Both the space the e and the s in "protestor" and the space between the t and the a in "protestor at" are precisely 3 pixels.Bawolff (talk) 01:25, 11 April 2014 (UTC)

This being tracked in bug 63807 but remains unconfirmed. (I haven't been able to replicate this exact kerning issue yet.) Steven Walling (WMF) • talk 23:19, 15 April 2014 (UTC)

Why - why - why?[edit | edit source]

User Nemo asked me to put the comments I placed on the talk page of Steven Walling (WMF) on this page.

Please undo the changes (at least on the Dutch Wikivoyage) as soon as possible. The type face for the top level headings is not acceptable. The reading ergonomics are quite poor. Look at the way the numbers are presented. Also the high characters are too much higher than the other characters. This makes it acceptable for the page title, but not for the "==heading==" that is used more often on a page. --FredTC (talk) 07:33, 5 April 2014 (UTC)

Hey FredTC: you might be interested in the rationale for the new headings which is detailed at the FAQ. Thanks, Steven Walling (WMF) • talk 21:12, 5 April 2014 (UTC)
I did read the FAQ, but it does not explain several things that are the most disturbing:
  • Why are H1 and H2 serif, and H3, H4, H5 sans serif on laptop/desktop (looks ugly), and why is H1 - H5 always serif on android smartphones (looks much better)?
  • Why does "18 Lettertype veranderd" have to look like "18 Lettertype veranderd"? The big difference between high letters and low letters makes it difficult to read. It could be OK if it appeared just once on a page like H1, but with H2 also in this type face the readibility becomes a problem.
  • Why does "5 DSM" have to look like "5 DSM"? I found out how this is called, and reading the article on Wikipedia about it, I learned that it is described in terms of "old style", "antique figures", "medieval". All words that say "not of modern times". So why is this type face selected? --FredTC (talk) 11:10, 6 April 2014 (UTC)



FredTC, I suggest you to ask these questions on mw:Talk:Typography refresh: Edokter (an admin) is very helpful in answering, see for instance mw:Talk:Typography refresh#Height/width issue & Russian wiki issues (ST vs CTT, СГT, 1234567890). --Nemo 13:18, 6 April 2014 (UTC)

--FredTC (talk) 13:47, 8 April 2014 (UTC)

Nimbus Sans L[edit | edit source]

Today we spent some time testing a stack that puts Nimbus Sans L first, before Helvetica Neue. This is the font that currently most Linux users (we've tested on Ubuntu and Debian) are getting via matching to Helvetica regular. The thing we tested for primarily is how this font renders on Windows, for the users who may have it. So far it unfortunately appears that for Windows users with ClearType turned off, Nimbus Sans also suffers from bug 63512, like Liberation Sans does. (Screenshot from a Windows 7 machine I have for testing).

I would like to keep trying to find a freely-licensed font that A) matches the other neutral sans-serifs that we have specified and B) which we feel comfortable putting first in the stack, meaning that it renders well on Windows, Linux, and Mac on major browsers. So far we are still coming up short. Steven Walling (WMF) • talk 02:20, 9 April 2014 (UTC)

Have we tried Open Sans and Droid Sans? These two fonts are becoming increasingly popular and more present on newer systems from what I remember seeing. I believe both are freely licensed under the Apache License. --GeorgeBarnick (talk) 02:33, 9 April 2014 (UTC)
Thanks for the good ideas. We've considered Open Sans in the past, but I believe it was rejected because Open Sans is a very different style of sans-serif than what we're shooting for with our design goals. It's a humanist sans-serif more akin to Verdana or Tahoma, rather than a more neutral Grotesk-style sans like Helvetica. Droid is not something we've talked about, though it perhaps seems odd to choose Droid Sans but not Droid Serif. @Vibhabamba: can you comment more? Steven Walling (WMF) • talk 03:33, 9 April 2014 (UTC)
GeorgeBarnick, Steven Walling (WMF) We are looking for open source alternatives that are stylistically close to the neutral characteristics of the letterforms most users see today. Both Arial (Default on Windows), Liberation Sans (used on linux), Helvetica (Default on Mac os) have good good x heights and look like derivatives or relatives of each other to readers. Open Sans, Droid Sans have very strong stylistic forms which create an inconsistent experience. There is a strong departure from what traditional Wikipedia feels like. Vibhabamba (talk) 08:41, 10 April 2014 (UTC)
Can I ask, where did you source the Nimbus fonts for Windows? I do not know of any software for Windows that bundles it, and I could barely find an up-to-date Ghostscript package containing the TTF versions, and I'm a font hoarder that knows how to find fonts! Also, the font-family names don't even match ('NimbusSanL' instead of 'Nimbus Sans L'). In other words, I believe that hitting a Windows system with a working copy of Nimbus Sans L is next to zero. Unless I'm wrong here, I think it is actually very safe to start with Numbus Sans L. Edokter (talk) — 09:42, 9 April 2014 (UTC)
OK, I found the GhostScript installer for Windows, same TTF fonts. It is still designated 'NimbusSanL', so no problem there. It also used to be installed with older versions of OpenOffice, but have since been replaced with Liberation/DejaVu fonts. So I'm still wondering how you managed to make "Nimbus Sans L" work on Windows. Edokter (talk) — 10:56, 9 April 2014 (UTC)
What if you move Nimbus Sans L to be the last on the font stack? On linux systems, thanks to the powerfull fontconfig, glyphs are automatically mapped to Nimbus Sans L or Liberations Sans if Arial isn't installed. For glyphs that aren't included in Arial, fontconfig will then use Nimbus Sans L. And on Windows nothing will display in Nimbus Sans L. Schulu (talk)
Are you saying you would prefer Arial (if installed) over Nimbus Sans L on Linux? Edokter (talk) — 14:24, 9 April 2014 (UTC)
Yes, I am. We have to face the fact that the majority of the users is on Windows. The differences between Arial and Helvetica (Nimbus Sans is a clone of it) is negligible and I bet most of the users can't see them on a Linux system. And on Windows the rendering of Arial is far better then the rendering of Nimbus Sans. The only problem that could rise is that the version of Arial in the core fonts package (which is in most repos of Linux distributions) is quite old and hasn't as many glyphs as the newer versions on Windows. But as I mentioned above, fontconfig will replace the missing glyphs with glyphs from Liberation Sans and Nimbus Sans. So I suggest the following font stack: "Helvetica Neue", Arial, Arimo, "Nimbus Sans L" --Schulu (talk) 07:28, 10 April 2014 (UTC)
I did two comparison shots, one with Arial, the other with Nimbus Sans on a Linux System with RGB subpixel smoothing and slight hinting. Can you tell which screenshot shows Arial and which Nimbus Sans? --Schulu (talk)
That is remarkably close (but the first link is Arial) and I don't see any difference in rendering. In that regard, and noting Nimbus has better glyph support then the core fonts Arial version, and the fact that many user prefer free fonts, I would not recommend putting Arial before Nimbus Sans. My recomendation would be (for Latin): "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif. Edokter (talk) — 12:14, 10 April 2014 (UTC)
Yes, it renders the same, but that's on a Linux system. If we put Nimbus Sans first, then Windows users would face this rendering: And that just looks bad. It looks better on browsers with Direct Write enabled like Firefox and IE, but considering Chrome has now a major user share and still relies on old GDI rendering on Windows we can't put Nimbus Sans first until Google fixes this bug/feature request: --Schulu (talk)
That is why I asked Steven where he found Ninbus Sans L for Windows. Apart for maybe some very old OpenOffice installations, the only other option to install the Nimbus fonts is through the Ghostscript drivers for Windows, which I think is next to zero. And even then, the font-family names do not match. There is no dedicated software installation for Nimbus fonts that I know of; only those knowledgable about those fonts may have installed them. Edokter (talk) — 13:20, 10 April 2014 (UTC)
Yes, you are right. The font choices you suggest further below seem the sanest. --Schulu (talk) 15:49, 15 April 2014 (UTC)

Rendering on Linux systems[edit | edit source]

Actualisation de la typographie - Linux nouveau.png
Here is how Nimbus Sans L is rendered on my Linux system. (This is a screenshot from frwiki without any special settings. Since it still has Helvetica in the stack, I get Nimbus Sans L).
For me, the characters are much smaller than when I force "sans-serif" (i.e. DejaVu Sans). This is more or less ok for normal text (I find it more blurry, but it's probably subjective). However, for the left menu text, tabs and links in the upper left corner, it is really too small and some characters are glued together (see for instance the rendering of the Watchlist link "Liste de suivi", the talk tab "Discussion", the link in the left menu "Débuter sur Wikipédia).
Orlodrim (talk) 22:45, 12 April 2014 (UTC)
This is a problem of your linux distribution or your modifications of the font rendering. For me it looks like you have set "hinting: full" and "rendering: grayscale". DejaVu Sans displays ok because it has hinting instructions which make the font readable when fontconfig jams it into a pixel grid. Nimbus Sans doesn't have such instructions. To get the rendering of both hinted and non-hinted fonts consistent you have to set hinting to "slight" or "none". The only distro that gets this richt is Ubuntu. On other distros you have to set this manually. --Schulu (talk) 15:49, 15 April 2014 (UTC)

Body font size is too large[edit | edit source]

YesY Resolved

So I eventually found a link to this page. I will re-iterate what I posted at Village pump (technical): "I don't think Wikipedia should appeal to people with an attention span of barely a paragraph or 140 characters. The larger font size requires way too much scrolling and eye movements. At least be consistent and reduce the font size of the other text on the page as well so I can use the browser's zoom functionality to get a readable appearance." So why did you only increase the text size of the body while all the other text on the page (side bar, buttons, references in the page, etc.) remain at their old sizes? If at least I could zoom out in my browser, but now whatever zoom setting I choose (100% or 90%) either the body text is too large or all the other text is uncomfortably small. 21:12, 9 April 2014 (UTC)

I believe they avoided changing the site-sidebar font-size, because that would lead to line-wrap issues at many (if not most) wikis. One of the earlier iterations did change that aspect, and resulted in numerous complaints, eg this thread and screenshot from November.
The current change to the body size (from 0.8em to 0.875em (essentially going from 12.8px to 14px)) is a better default for accessibility, and has led to a lot of comments about "not having to squint anymore". I think we'll eventually need a more customizable interface (eg this menu as seen at NYTimes), but this change will benefit a lot of readers/editors in the meantime. (I understand where you're coming from - I prefer paperbacks with very small fonts, to hardbacks with larger fonts - but I also believe this change is for the general good). Hope that helps. –Quiddity (talk) 22:03, 9 April 2014 (UTC)
In, zh wp, Body font size is small--Shizhao (talk) 14:53, 10 April 2014 (UTC)
Shizhao The size has actually increased by one size, so it shouldn't be too small. Comparing this to other Chinese-language sites like Baidu this seems roughly similar. Steven Walling (WMF) • talk 23:34, 15 April 2014 (UTC)
Currently we get a lot of feedback that users are having to use browser zoom in order to be able to read the type on the site, which isn't acceptable, while we understand that some people what an high information density, we enlarged the font for accessibility reasons, and feel strongly about that. You can override it in your personal CSS or do a browser zoom to shrink the text if you'd like to view more content on screen at any given time. Jaredzimmerman (WMF) (talk) 23:42, 15 April 2014 (UTC)

Pretty stock Windows XP machine[edit | edit source]

YesY Resolved: bug filed and should no longer be an issue for now, since we changed back to "sans-serif" for body

Just two screenshots:

Bolded search results after Apr 2014 typography refresh
Unreadable article body font after Apr 2014 typography refresh

This is Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1925.0 Safari/537.36 on a pretty stock Windows XP (with updates). Especially annoying on Sony Vaio VGN-Z21WN crispy, high-DPI screen.

 « Saper // talk »  22:44, 9 April 2014 (UTC)

You have some version of Helvetica installed. Also, turn on ClearType; this is pretty essential, especially on HiDPI screens. Edokter (talk) — 23:23, 9 April 2014 (UTC)

I can try cleartype with IE8:

With cleartype

Also cleartype disabled there (similar to Chromium issues above)

No cleartype

I don't know why having Helvetica installed breaks display of MediaWiki content so bad; also ClearType is difficult to enable on this OS and until now it wasn't really necessary. ClearType looks better in this case but overall look is amateurish.  « Saper // talk »  10:16, 10 April 2014 (UTC)

There are many bad Helvetica knock-offs floating around the net, and some HP printer drivers also installs a badly designed copy. (Basically, only versions by Linotype are decent.) Simply removing such a font will usually fix that issue. Edokter (talk) — 12:27, 10 April 2014 (UTC)
@Saper: Erwin is correct here. This is also tracked in bug 63720. We can't control 100% for what fonts users or systems like HP printers install on a user's machine, but I may test putting Arial before Helvetica in the stack. (The primary impact would be on Windows and Linux users. The danger being that putting Arial first might change what font is presented to Linux desktop users.) Steven Walling (WMF) • talk 17:41, 10 April 2014 (UTC)
@Steven (WMF):, see #Nimbus Sans L above. With Nimbus at the start, putting Helvetica after Arial may not be a bad idea. Edokter (talk) — 20:34, 10 April 2014 (UTC)
Or, you know, "sans-serif"... So that instead of fooling around endlessly with the order of a stack to try and force it, and second guessing what might work on every OS/browser, with subpar results for many users, because you can't guess/force them all; the OS/browser decides for itself in the standard, proven fashion. Just saying...
adding: Oops, didn't notice Nemo already said this above, while he was referring to beta testing at Typography_refresh/Font_choice/Test#Pre-conclusions also supporting it. Take this as agreement, then. Begoon • talk 11:08, 12 April 2014 (UTC)
There is now a new font stack in place (local to only) to test a different font ordering, that should not cause Windows to use bad font, but should result in a more consistent look accros platforms. Edokter (talk) — 11:56, 12 April 2014 (UTC)
Where still guessing (or rather hoping) that Windows users have neither "Nimbus Sans L" nor "Helvetica Neue" installed if I'm not mistaken... --Patrick87 (talk) 12:02, 12 April 2014 (UTC)
If they do have those fonts, they should not match these rules because the font family names differ on Windows. I'll post a breakdown below. Edokter (talk) — 12:28, 12 April 2014 (UTC)

Chinese title[edit | edit source]

In Chinese, serif title no clean. see zh:黃花水芭蕉 and en:Lysichiton americanus--Shizhao (talk) 14:55, 10 April 2014 (UTC)

Shizhao, We're working with Chinese, Japanese, and Korean wikis to make sure that the stylistic integrity is preserved while making sure that the headers are readable in non-latin scripts. Thanks for your feedback Jaredzimmerman (WMF) (talk) 23:33, 15 April 2014 (UTC)

Missing minus sign[edit | edit source]

Missing minus sign (IE9/Win7); there should be a minus sign between the quotation marks „“

Thanks to the new typeface, the minus sign isn't displayed anymore (Internet Explorer 9 on Windows 7)... Readability is horrible with the new typeface, I hope this gets fixed or reverted soon. --SelfishSeahorse (talk) 18:55, 10 April 2014 (UTC)

That also seems like a "Helvetica" bug; Windows mistakenly uses a narrow variant because it can't find the main font, ie. it uses the first font that matches the font-family name. (Do you have Helvetica Narrow installed, but not Helvetica?) Edokter (talk) — 20:46, 10 April 2014 (UTC)
Hi and thanks for your reply! There are a bunch of Helvetica fonts installed on this system - narrow and normal ones. Unfortunately, when I visit Wikipedia (but not Mediawiki, which is quite strange) it seems to choose the tiniest of them, which doesn't support the minus sign (U+2212). Is it possible that the problem occurs because none of these Helvetica fonts is just called Helvetica? They all have names like Helvetica 45 Light, Helvetica 55 Roman, Helvetica-Normal, or Helvetica-Narrow. --SelfishSeahorse (talk) 08:51, 14 April 2014 (UTC)
The reason you don't see it here is possibly because is testing a new font stack. You do seem to have a range of different helvetica fonts installed. The first two you mention seem to be part of the Helvetica Neue family, the other may be the classic fonts. You may have some font substitutes active that causes the wrong font to be used. But it is hard to determine the exact cause. Edokter (talk) — 17:02, 14 April 2014 (UTC)
SelfishSeahorse, I can't seem to reproduce this, are you still seeing this issue as of today? I'm not seeing any font rendering issues or bugs, if you are able to reproduce still, please let us know what fonts your browsers is showing for this text, you can find how to "inspect" the type here let us know if this has been fixed for you now, thanks! Jaredzimmerman (WMF) (talk) 23:22, 15 April 2014 (UTC)
Hi Jaredzimmerman (WMF)! Sorry for not replying sooner. Fortunately this issue seems to be fixed now. Articles on Wikipedia are finally readable again! Thank you! SelfishSeahorse (talk) 12:58, 24 April 2014 (UTC)

New font stack breakdown[edit | edit source]

I have proposed a new font stack (for Latin languages only) on wikitech-l, and after some feedback I was asked to test it here on So here it is:

font-family: "Nimbus Sans L", "Helvetica Neue", Arial, Helvetica, sans-serif;

Breakdown[edit | edit source]

Nimbus Sans L[edit | edit source]

For Linux. This is the defacto Helvetica font on Linux systems which result in an look similair to Mac/Windows. Windows will not match this font, as the Windows versions of the Nimbus font packages have different font family names (ie. 'NimbusSanL' instead of 'Nimbus Sans L').

Helvetica Neue[edit | edit source]

For Mac. Like Nimbus, this should not match fonts on Windows (or Linux for that matter), as those copies for Windows have different font family names (such as 'HelveticaNeueLT Com 55 Roman').

Arial[edit | edit source]

For Windows. Positioned after Nimbus Sans and Helvetica Neue, so Mac and Linux do not match Arial, but positioned before Helvetica to prevent matching an inferiour Helvetica font that may be installed on some Windows machines.

Helvetica[edit | edit source]

Generic Helvetica fallback for any system not matching any of the previous fonts.

I am quit confident this makes everyone happy because 1) every OS should end up using a native font, and 2) it "promotes" a free font at the beginning of the stack (not a high priority in my book though). Edokter (talk) — 12:36, 12 April 2014 (UTC)

Discussion[edit | edit source]

The test stack does result in Arial for me (XP SP3, Chrome 33). I have Nimbus Sans L, Helvetica, but not Helvetica Neue installed. So providing someone can confirm Helvetica Neue on Windows doesn't break it, at least that would give legible fonts again (although I still question the wisdom of forcing stacks like this with the potential for problems for others we have seen - e.g. Linux, above. "sans-serif" is surely adequate, standard, and sensible). The rest is then a matter of my preferences - I still dislike the size and serif headers, but the body type is not broken and badly rendered any more, so my major concern for logged out or non technical users is addressed by that, thanks (assuming it's implemented). Begoon • talk 16:28, 13 April 2014 (UTC)
Helvetica Neue rendering on Windows
I have Helvetica Neue on Windows, attached a screenshot of what it looks like for me (I rather like it). --Skizzerz 04:25, 24 April 2014 (UTC)

Header fontstack[edit | edit source]

See also: Header test

As an experiment, the test wiki has a new font stack for the serif headers:

font-family: "Nimbus Roman No9 L", "Times New Roman", Times, serif;

Reason: the 'Linux Libertine'/'Georgia' stack is too inconsistent. Stylistically worlds apart and their sizing is also very different. Georgia's use of en:text figures is also an eyesore to many. Perhaps ironically, the middle ground in both style and size between these two fonts is provided by Times (New Roman). Where serifs are concerned, Times is as neutral as Helvetica is for sans-serif. It is also the most ubiquitous serif amongst platforms, which helps consistency. Thoughts? Edokter (talk) — 14:03, Today (UTC+2)

(Edit:) Another reason Georgia is not fit for a global font stack is that it only supports Latin/European scripts. Like the body font, perhaps the default should be 'serif' and Georgia should be reserved for Latin stacks only. Edokter (talk) — 09:02, 24 April 2014 (UTC)

Times New Roman is ugly. While it is legible, esthetically it just does not look good. Since we don't really need to aim for maximum legibility for headers (they are rendered large enough to be easily readable even on the smallest screens) but actually want to give Wikipedia some characteristic look by the use of serif headers, I'd abstain from using Times. --Patrick87 (talk) 16:42, 14 April 2014 (UTC)
That is a matter of opinion; I like Times' neutrality. Do you have a suggestion for a serif that you do like? Edokter (talk) — 16:49, 14 April 2014 (UTC)
Actually I'm fine with Georgia. It looks "smoother" compared to Times New Roman. Actually Times is too narrow for my taste which doesn't look too well in headers. What you describe as "neutrality" seems rather sterile to me. Times might be a fine font for body text (as it doesn't draw any attention) but I assume that's the exact opposite of what we want to achieve with headers.
As for a free font I don't have a good option at hand right now. Linux Libertine is quite close to Times I'm afraid, but at least it's the font used in our Wikipedia Logo. Therefore I think it's a fine choice at least in that respect and I wouldn't replace it with Nimbus Roman No9 L. --Patrick87 (talk) 23:48, 15 April 2014 (UTC)
You are right that Times New Roman is a very ubiquitous font. It's the default serif font for Internet Explorer and widely used in the world of academia and law. For some reason it has not been optimized for screen in all its weights. The Bold weight is a fat or heavy and is altogether a different style than the regular weight, The italic weight is also too wide which would create an issue to a lot of articles that are set in nouns for Wikipedia Article Pages. The capitals are too heavy and wide, Specifically, the kerning on screens is weak without antialiasing, which i'm not sure we can count on. Some lower case characters when set in non standard sizes lowercase 'e' is cramped and strangely offsets to the left. In general its a default font, but there is little evidence that its been optimized for screens. Also for windows users who don't have georgia, TNR will be the fallback font. Vibhabamba (talk) 20:12, 16 April 2014 (UTC)
All Windows/Mac users have Georgia, and many Linux users have too. The main problem I have with Georgia is its use of text figures. I can disable that for Win/Mac, but not for Linux because they are stuck with an pre-OpenType version of Georgia. I still don't know what Linux Libertine is doing there; it has a very low install base, and is the stylistic counterweight of Georgia. Edokter (talk) — 20:27, 16 April 2014 (UTC)
Sorry, but how many headers actually contain numbers? It's very rare and even if a header happens to contain a number the use of text figures is not an issue at all. It's only that people are not even used to serif headers yet, therefore blaming the seemingly evident "flaw" of "misaligned" numbers is one way to express this. I bet if you give Georgia two weeks, nobody will actually notice the text figures anymore. Does anybody have a real issue with them? I doubt it... --Patrick87 (talk) 20:42, 16 April 2014 (UTC)
More then you think, predominantly in article titles. And yes, they are a real problem in some scripts, mainly CJK. Text figures are OK for body text but are not suitable for headers. Edokter (talk) — 01:27, 17 April 2014 (UTC)
Georgia is a lovely screen font, and has a wide distribution. Sadly, the text figures rule it out from being used as title font. I'm not enthusiastic about Times New Roman, but it may well be the only viable serif alternative. If the size is large enough it's OK, even without smoothing.
OTOH, why not take "serif" for titles? It will be Times in 90% of cases, but I can change my default serif to "Cambria" or whatever. Power to the user.
OTthirdH, I played around and found "Trebuchet" an interesting contrast to Arial. So, if it doesn't have to be a serif, this would work IMHO. -- 22:29, 20 April 2014 (UTC)
The edited in reason to abandon Georgia (no support for non-Latin characters) is the first argument I'd accept (the rest seemed more or less like personal preferences to me). However I think we should consider increasing the size of <h1>,<h2> headers then. I just tested on Windows with "Times New Roman" and they look tiny. E.g. the size of serif <h2> headers is not much larger than the bolded sans-serif <h3> headers. Because of the bolding (and the narrow font face of Times New Roman) <h3> headers look even more prominent than the <h2> headers do! --Patrick87 (talk) 09:28, 24 April 2014 (UTC)

Problem with accented characters[edit | edit source]

Using Firefox 25.01 on OS 10.6.8, accented characters show up as bold and their kerning is off, both in headers and in ordinary text. Using Safari 5.1.10, only the kerning problem is visible if you look closely. See en:Japanese ironclad Fusō for an example. I do have MS Office 2008 installed. The problem goes away if I use OS 10.9.2 with all the latest versions of Firefox and Safari.--Sturmvogel 66 (talk) 19:22, 13 April 2014 (UTC)

It would help if you could upload a screenshot so we can see the problem. Edokter (talk) — 20:42, 13 April 2014 (UTC)
Upload it to Commons?-- 21:50, 13 April 2014 (UTC)
You can upload it here as well. It is not of much use on Commons. Edokter (talk) — 21:53, 13 April 2014 (UTC)
Didn't much think so. I'm not running MediaWiki on my Mac, so how do I enable uploads since I don't have php?--Sturmvogel 66 (talk) 00:42, 14 April 2014 (UTC)
You don't have to run PHP or MediaWiki; just ckick "Upload file" (under "Tools") in the menu on the left. Edokter (talk) — 16:53, 14 April 2014 (UTC)
Doesn't show up as an option in my sidebar.-- 22:23, 14 April 2014 (UTC)
Ah OK, I guess you need to be registered (also on Commons for that matter). Edokter (talk) — 22:51, 14 April 2014 (UTC)
I am logged in here and on Commons. Is that what you mean?--Sturmvogel 66 (talk) 02:33, 15 April 2014 (UTC)
Yes. Edokter (talk) — 10:42, 15 April 2014 (UTC)
@Sturmvogel 66: Hi, I'd recommend uploading your screenshot to a temporary location for now (I tend to use which doesn't require registering or anything), or waiting for 14 more hours, because to upload files here or at Commons, your account needs to be "Autoconfirmed", which takes 4 days at those 2 wikis. Hope that helps. –Quiddity (talk) 05:08, 17 April 2014 (UTC)

Other nitpicks[edit | edit source]

  1. While the font color has been changed to #252525, the headers remain black. At least for the (bold) H3 and down, this sticks out too much. Should the headers follow the body text?
  2. The H3 size is slightly too small; it renders 16px, only marginally larger then H4 (100% / 14px). This makes pages like ResourceLoader/Default modules hard to decypher. Suggest changing font-size to 1.2em (renders at 17px).
  3. The 1.6em lineheight for body text only affects <p> sections; lists, often used for indenting in discussions, still render at 1.5em lineheight, which is inconsistent. Should <dt>/<dd>/<ol>/<ul> follow <p> in line-height?

Edokter (talk) — 10:45, 14 April 2014 (UTC)

The headers are darker so they stand out, this is intended based on reading behaviors. Readers skim article and section headers act as entry points in an otherwise dense wall of text. All colors have been contrast evaluated and conform to W3C AAA Guidelines. Thanks Vibhabamba (talk) 23:23, 15 April 2014 (UTC)
  1. Change it all back to black, then it's consistent. Actually one of the WMF devs even claimed one of the "features" of the gray body text would be to "make the headers stand out more". I dislike grayish text altogether – there's nothing gained by it's use. The only thing we loose is contrast for no reason.
    Please be aware that we have many audiences that engage in long form reading and are not aware of how to adjust screen brightness. Typically an older demographic. We have feedback from readers which establishes that black on white vibrates for readers on bright screens when engaged in continuous reading. Also we are not 'loosing' contrast with changing from all black to #252525. #252525 provides sufficient contrast by the most stringent accessibility standards. See Vibhabamba (talk) 23:28, 15 April 2014 (UTC)
    "Suffucient" and "not loosing" are two different things. We loose contrast, that's pure math. If it might or might not be sufficient is a subjective measure heavily dependent on vision of the individual and the available hardware. I asked before where the feedback is that claims pure black on white would cause issues (without an answer) and I asked before where in those standards it is stated that more contrast wasn't allowed (without answer). I'd appreciate some evidence on how grayish text should increases legibility (if available), otherwise I'm tempted to call this decision a designer's whim, poorly supported by the fact that contrast is at least not too low. --Patrick87 (talk) 00:04, 16 April 2014 (UTC)
  2. Agree.
  3. Agree. Actually I think it is time for a major UI refactoring (not to make everything look different but to make everything look consistent). Every feature that is added by the WMF (e.g. Flow, VisualEditor, Hovercards, MediaViewer, etc.) adds a new set of it's own styles instead of reusing CSS that is already available resulting in an overall inconsistent look. I don't even start talking about the unnecessary complexity, aggravated maintenance or performance. --Patrick87 (talk) 16:51, 14 April 2014 (UTC)
Patrick87, Flow and Visual Editor have both been able to significantly simplify their code post typography refresh in order to have greater consistency as users navigate from page to page and mode to mode, wikipedia/mediawiki are so vast and complex that if you look you will surely find pages that are inconsistent, but we plan to, and are actively removing page and feature specific overrides in order to get greater consistency across the projects. If there are pages, or features where you see a lot of overrides being used I'd appreciate the help logging bugs we can clean up the code in those cases. Thanks! Jaredzimmerman (WMF) (talk) 23:47, 15 April 2014 (UTC)
That is good news. I appreciate that this is actually worked on.
However I'm afraid that Flow (whatever amount of code simplification was possible so far) is a paragon of inconsistency. It looks nothing like the rest of Wikipedia but rather like an independently developed extensions that is forced into the existing layout at most half-heartedly. I'll have an eye on it though and report if I find any obviously unwanted inconsistencies. --Patrick87 (talk) 00:15, 16 April 2014 (UTC)
@Patrick87: There's an ongoing massive reworking of the front-end, one of the items in which is "be in line with typography refresh". So, ignore the current front-end design inconsistencies for a few more weeks, please. :) Quiddity (WMF) (talk) 04:54, 17 April 2014 (UTC)
For [1]: I second "change it all to black". Using dark grey text can be an option to reduce contrast, in the appropriate circumstances, and I sometimes use it in images, and used to use 90% black text occasionally on physically printed pages when I was an "ink on paper" printer. However, in that case, we had control of the final output (a printing press) and product (a printed piece of paper).
It's not appropriate here, because in this case we do not have control of the many and varied output devices (monitor types/mobile devices et al.), and so should leave the adjustment of such devices to the user, without reducing their options or range. The user can reduce contrast to taste - he cannot add back what has been removed. The fact that a guideline can be found which says this doesn't reduce contrast "too much", does not alter the reality that it does reduce it, and thus the end user's options. We shouldn't do that.
I tend to agree with Patrick, here, that this looks a lot like a "designer's whim", rather than anything else. Also, I have no idea what "vibrate" is supposed to mean in this context.
For [2] and [3]: Edokter's suggestions seem sound and sensible, promote consistency, and should be implemented. Consistency is a good thing. Begoon • talk 11:02, 16 April 2014 (UTC)
Yep, I certainly get the feeling that (per the FAQ) designer's whim and anecdote drive this typography refresh. When we we learn to use proper controlled tests? Rich Farmbrough 16:58, 17 April 2014 (UTC).
Re "The user can reduce contrast to taste - he cannot add back what has been removed", but he usually can. Most monitors have contrast settings - it used to be a simple dial or pair of buttons, now it's generally hidden in the settings menus, but it's common if not almost universal. Or he can adjust the gamma settings. Or brightness settings. Or adjust the ambient lighting.
Chances are he's already done so as many web sites have other than black on white contrast. Not only is non-black text common, with grey being the most common colour, but non-white backgrounds are too. I just had a look at my four favourite news sites (CNN, WP, BBC, and all use grey text, sometimes combined with black headings. And those are among the most conservative and soberly formatted websites. It wouldn't be hard to find some with more extreme variations.
So FWIW I support it; it seems a decision in line with good and common practices on the web.--JohnBlackburne (talk) 21:57, 22 April 2014 (UTC)
No John, the user really can't do what I said. If, for instance, for reductio ad absurdum, the site reduced the contrast to "dark grey on dark grey", there is nothing he can do with his monitor controls or Ikea lamps to make it legible. It is lost.
Back in the real world, you can "simulate" increased contrast over the original, but it ain't real. The visible image contrast adjustment range available will always thus be less than it was previously. It can't be otherwise. Consider, for this thought example, the poor man with the knackered old screen who already has his contrast knob forced "all the way up" to get what he wants. You reduce the contrast at source. What does he do with his knob now?
For context we're talking monitor controls here - obviously you can do what you like with custom CSS etc - the ASCII characters are there - but that's not this discussion. Nobody is denying that tech savvy users can have purple text on an orange background if they like, by editing stylesheets etc. The discussion concerns users who can't, won't, or should not have to do that. A knob on a screen will not replace reduced contrast range for them. It just can't. You have, in effect, limited the abilities of that knob.
Now your argument that other websites have done it, that you like it, that other users like it, that it has caused no problems there, is valid, but separate. OTHERSTUFFEXISTS can be perfectly valid here, when expressed as well as you did. But that is not the same argument. I say, as a global, textual website, we shouldn't remove contrast options. You think it's ok. They're both fine views, but they're not both about monitor contrast adjustment. That's where we failed to mesh. This site has reduced that available range for non technical users, by default, including non-logged in users/new readers, and I disagree with that choice. That's all. Begoon • talk 13:41, 23 April 2014 (UTC)

Italic article titles[edit | edit source]

First of all, my apologies if this is in the wrong place or has been discussed ad nauseum, I contribute to the English Wikipedia and have looked all over for somewhere to post this.

For articles that have italic titles I noticed that the lower-case v looks a lot like a u. When I compared this to non-italicized titles I noticed that they are virtually 2 different fonts! The lower-case i, for example, looks like a nice, readable serif font, but when it's italicized it looks like script. Surely the italics should look like a slanted version of the standard font. Is this intentional? nagualdesign (talk) 00:21, 23 April 2014 (UTC)

That is how Italic type are supposed to look like. Compare with Oblique type, usually used by sans serif fonts. Edokter (talk) — 01:41, 23 April 2014 (UTC)
Thanks for providing a distinction. Still looks funky to me, mind. Regards, nagualdesign (talk) 03:21, 23 April 2014 (UTC)