Last modified: 2014-04-14 23:13:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65512, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63512 - Typography refresh body type renders incorrectly in Windows
Typography refresh body type renders incorrectly in Windows
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.23.0
PC Windows 7
: High major with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
https://www.mediawiki.org/wiki/Talk:T...
: i18n
: 63511 63591 (view as bug list)
Depends on:
Blocks: typography-refresh
  Show dependency treegraph
 
Reported: 2014-04-04 03:44 UTC by Jared Zimmerman (WMF)
Modified: 2014-04-14 23:13 UTC (History)
20 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jared Zimmerman (WMF) 2014-04-04 03:44:57 UTC
More details here https://twitter.com/mrtnclzd/status/451926785672753152
Comment 1 Martín 2014-04-04 04:06:15 UTC
Windows 7 Professional SP1, Chrome: http://i.imgur.com/9QD1ujH.png
Windows 7 Ultimate SP1, Chrome: http://i.imgur.com/FvGdfln.png
Comment 2 Andre Klapper 2014-04-04 09:06:19 UTC
*** Bug 63511 has been marked as a duplicate of this bug. ***
Comment 3 Jon 2014-04-04 16:43:52 UTC
Do we know what version of Chrome? I'm struggling to replicate on browserstack.com
Comment 4 Martín 2014-04-04 21:09:18 UTC
I don't think it's the browser, both images are running 33.0.1750.154 m.
Comment 5 Martín 2014-04-04 21:10:06 UTC
(In reply to Jon from comment #3)
> Do we know what version of Chrome? I'm struggling to replicate on
> browserstack.com

I don't think it's the browser, both images are running 33.0.1750.154 m.
Comment 6 Steven Walling 2014-04-04 23:48:18 UTC
I am pretty sure this issue is being caused by Liberation Sans. Is it the case you  have it installed Martin?
Comment 7 Jon 2014-04-05 00:00:00 UTC
Could be related to browser zooming and the fact we now use ems ... https://twitter.com/TeaJunkie1/status/452230220876369920
Comment 8 Vibha Bamba 2014-04-05 00:21:03 UTC
Windows 7 does have Arial Regular. So the type might be defaulting to Arial Narrow.
If you have Open Office installed, Open Office carries the Liberation font stack.
So the font may be defaulting to Liberation Sans in some cases.
http://www.techrepublic.com/blog/windows-and-office/take-full-advantage-of-the-new-font-features-in-windows-7/

If you install Arimo - the first open source font specified in the font stack, you may see other issues such a fat F's, I's.
Comment 9 Martín 2014-04-05 00:29:13 UTC
(In reply to Steven Walling from comment #6)
> I am pretty sure this issue is being caused by Liberation Sans. Is it the
> case you  have it installed Martin?

No, unless it's under a different name, I don't see it listed.
Comment 10 Martín 2014-04-05 00:31:25 UTC
(In reply to Vibha Bamba from comment #8)
> Windows 7 does have Arial Regular. So the type might be defaulting to Arial
> Narrow.
> If you have Open Office installed, Open Office carries the Liberation font
> stack.
> So the font may be defaulting to Liberation Sans in some cases.
> http://www.techrepublic.com/blog/windows-and-office/take-full-advantage-of-
> the-new-font-features-in-windows-7/
> 
> If you install Arimo - the first open source font specified in the font
> stack, you may see other issues such a fat F's, I's.

http://i.imgur.com/zHMXiPZ.png
This is a screenshot with ClearType on, it's using Arimo, but when I turn it off it goes back to Helvetica.
Comment 11 Martín 2014-04-05 00:52:57 UTC
Fixed:

http://i.imgur.com/2VeMgNc.png

Thank you all for not making me turn on ClearType. Please don't hate me for not using it.
Comment 12 Steven Walling 2014-04-05 00:56:49 UTC
Thanks very much for the assistance Martin.
Comment 13 Bartosz Dziewoński 2014-04-06 11:12:57 UTC
*** Bug 63591 has been marked as a duplicate of this bug. ***
Comment 14 Bartosz Dziewoński 2014-04-06 11:14:21 UTC
See 63591 for a more detailed bug report.

So, what is the way forward here? Killing off Liberation Sans and Arimo?

Is somebody working on this?
Comment 15 piotr.jerzy.jurkiewicz 2014-04-06 13:30:50 UTC
(In reply to Bartosz Dziewoński from comment #14)
> See 63591 for a more detailed bug report.
> 
> So, what is the way forward here? Killing off Liberation Sans and Arimo?
> 
> Is somebody working on this?

It appears that en.wikipedia.org already have done that. Now they provide font-family: "Helvetica Neue",Helvetica,Arial,sans-serif. In my case it results in Arial on Windows 7 (instead Liberation Sans, see bug 63591) and Nimbus Sans L on Ubuntu 12.04 (instead Liberation Sans too). In my opinion it looks better now on both systems.
Comment 16 Jon 2014-04-06 16:25:43 UTC
we need to reevaluate these two fonts at least in the Windows context. I dropped them on enwiki as we'd had many reports that the font rendering was just broken and I was able to confirm there were problems with both Arimo and Liberation Sans and thus unreadable thus going against the whole ides of providing free knowledge.

Easiest thing seems to be to drop them. Is there anything else we could do to keep our free font commitment?
Comment 17 Bawolff (Brian Wolff) 2014-04-06 18:11:51 UTC
I'm kind of concerned that an issue was fixed *only* on enwikipedia. Issues that affect all wikis on cluster really should not be fixed on just a single wiki.
Comment 18 Jon 2014-04-06 18:16:03 UTC
You are correct Brian, this is very insufficient and it is a concern to me.

The idea was just to get through the weekend (other projects could copy this if they deemed it necessary). The plan is on Monday to lightning deploy a fix to all wikis making this change everywhere (We don't do lightning deploys on Fridays)

I will mail a long email with details and possible next steps to address the long term issue of finding a free font we can support sometime Monday. What this space.
Comment 19 Steven Walling 2014-04-06 19:01:23 UTC
(In reply to Bawolff (Brian Wolff) from comment #17)
> I'm kind of concerned that an issue was fixed *only* on enwikipedia. Issues
> that affect all wikis on cluster really should not be fixed on just a single
> wiki.

Brian: we definitely won't consider this bug resolved until we've fixed the problem on all Wikimedia wikis by properly changing core's Vector LESS styles. 

We tested and implemented local fixes on Beta Labs and English Wikipedia since it was a Friday and we wanted to get user feedback quickly via the Village Pumps etc. Jon will be putting a real patch in place and we have coordinated with the [[wikitech:SWAT deploys]] team to shoot for Monday. 

Bartosz: yes, for now removing Arimo and Liberation Sans is fixing the problem for XP and Windows 7 users. In the future we need to take a second look at see if there is any freely-licensed font that will render well for users without subpixel rendering. For now, this fix is what users are saying improves things.
Comment 20 Erwin Dokter 2014-04-06 19:14:42 UTC
If I see the term "free font commitment" one more time, I am going to scream...

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:

1. Free fonts render bad on Windows (at least without font smoothing).

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 diplay 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.

2. Only Latin script is targeted.

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.
Comment 21 Steven Walling 2014-04-06 19:21:21 UTC
(In reply to Erwin Dokter from comment #20)
> If I see the term "free font commitment" one more time, I am going to
> scream...
> 
> 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:
> 
> 1. Free fonts render bad on Windows (at least without font smoothing).
> 
> 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 diplay 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.
> 
> 2. Only Latin script is targeted.
> 
> 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.

I think it's exaggerating to say that, considering most Windows users do not in fact have Liberation Sans nor Arimo. For the Windows users without font smoothing turned on, Arial should work just fine. 

We plan on having a public retrospective in two weeks (see also: [[en:Retrospective#Software development]]) where we can talk about the process and results of the beta and first release. Your comments will be most welcome there Erwin, since you've definitely been in the thick of responding to questions/comments as much as anyone.
Comment 22 Bartosz Dziewoński 2014-04-06 19:46:02 UTC
To be clear, I think the rendering is worse on Windows 7 with ClearType enabled, too. Compare for yourself:

Screenshots from bug 63591 (they look zoomed out to me, or the reported just has smaller default font size):
* Liberation Sans: https://bugzilla.wikimedia.org/attachment.cgi?id=15031
* Arial: https://bugzilla.wikimedia.org/attachment.cgi?id=15032

My screenshots (everything default):
* Liberation Sans: http://i.imgur.com/ykhUWQh.png
* Arial: http://i.imgur.com/Hj9UoE4.png
Comment 23 Bartosz Dziewoński 2014-04-06 20:00:11 UTC
(In reply to Steven Walling from comment #21)
> (…) most Windows users do not
> in fact have Liberation Sans nor Arimo.

I'm going to call [citation needed] on this until I see some stats. :)
Liberation Sans is installed by default with LibreOffice, and the popularity of free office suites have grown in the recent years among Windows users too [1]. This is likely a non-negligible number of users.

[1] https://en.wikipedia.org/wiki/LibreOffice#Users_and_deployments provides
    a ton of sources.


(In reply to Erwin Dokter from comment #20)
> 2. Only Latin script is targeted.
> 
> (…)
> 
> 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.

I think this is a very good point that should be seriously considered.
'sans-serif' might be the best way to go by default after all. (Please note that I wasn't among the people opposing the font stack that was chosen.)
Comment 24 Nemo 2014-04-06 20:02:41 UTC
(In reply to Erwin Dokter from comment #20)
> 
> 2. Only Latin script is targeted.
> 
> 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.

+2
Comment 25 Steven Walling 2014-04-06 20:22:17 UTC
(In reply to Bartosz Dziewoński from comment #23)
> (In reply to Steven Walling from comment #21)
> > (…) most Windows users do not
> > in fact have Liberation Sans nor Arimo.
> 
> I'm going to call [citation needed] on this until I see some stats. :)
> Liberation Sans is installed by default with LibreOffice, and the popularity
> of free office suites have grown in the recent years among Windows users too
> [1]. This is likely a non-negligible number of users.
> 
> [1] https://en.wikipedia.org/wiki/LibreOffice#Users_and_deployments provides
>     a ton of sources.

I certainly didn't say it's a negligible amount. I said "most". We obviously think  it's enough to require removal of the two fonts.
Comment 26 Bartosz Dziewoński 2014-04-06 20:37:44 UTC
(In reply to Steven Walling from comment #25)
> I certainly didn't say it's a negligible amount. I said "most".

Right, it's probably not over 50%.
Comment 27 Bawolff (Brian Wolff) 2014-04-06 20:56:09 UTC
> 
> 2. Only Latin script is targeted.
> 
> 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.

Sorry to hijack this, but given the very issue was discussed a month and a half ago ( http://lists.wikimedia.org/pipermail/wikitech-l/2014-February/074478.html ), how did that end up being an oversight?
Comment 28 Erwin Dokter 2014-04-06 22:17:17 UTC
(In reply to Bawolff (Brian Wolff) from comment #27)
> 
> Sorry to hijack this, but given the very issue was discussed a month and a
> half ago (
> http://lists.wikimedia.org/pipermail/wikitech-l/2014-February/074478.html ),
> how did that end up being an oversight?

Because it was quite deliberately ignored. Reading up on past discussion, I also found [1], where TheDJ was echoing my exact thoughts as I do now. Mobile is also not comparable to desktop systems, as mobile fonts are usually very limited and easily overridden by the devices for non-latin scripts.

Steven's response was that Wikipedia needed to be more inline with other world class sites with their flashy typography. But he does not realize that sites like Microsoft, Yahoo and Google/Gmail have well-funded local web staffs and an infrastructure that *does* serve specific- and well-researched font stacks based on the user's language, and potentially OS; something that Wikipedia's current indrastructure is incapable of doing.

So I will stress again that this should be classified as an per-project issue, not a global one; One universal font stack for the entire world is an illusion.

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-February/074519.html
Comment 29 Steven Walling 2014-04-06 22:22:38 UTC
(In reply to Erwin Dokter from comment #28)
> (In reply to Bawolff (Brian Wolff) from comment #27)
> > 
> > Sorry to hijack this, but given the very issue was discussed a month and a
> > half ago (
> > http://lists.wikimedia.org/pipermail/wikitech-l/2014-February/074478.html ),
> > how did that end up being an oversight?
> 
> Because it was quite deliberately ignored. Reading up on past discussion, I
> also found [1], where TheDJ was echoing my exact thoughts as I do now.
> Mobile is also not comparable to desktop systems, as mobile fonts are
> usually very limited and easily overridden by the devices for non-latin
> scripts.
> 

I'm sorry, but you're wrong. These are not the same issues. As Patrick noted in his comments, "By chance (mainly to create SVGs for Commons) I have the fonts "Liberation Sans" and "DejaVu Serif" installed on my system."

A singly user willfully choosing to download a set of fonts is not the same thing as thousands of users unknowingly having the fonts packaged with another application. If users specifically choose to download a font, like Linux Libertine for instance, and then report to us that they think it's not what they like, then the onus is on them. The case where users of LibreOffice/OpenOffice have these fonts plus having font smoothing off (intentionally or because that's their system default) is a whole different can of worms.
Comment 30 Nemo 2014-04-06 22:39:26 UTC
From http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075721.html
> TL;DR: one user saying they chose to download the fonts in question is not
> the same thing as a report that a significant minority might have them.

Please establish a number of scapegoats and guinea pigs that one has to sacrifice for Steven Walling the god of fonts to accept that something is going to go bad. AFAICS, people had anticipated that several billions of world inhabitants (those speaking non-Latin script languages) were going to be almost surely negatively affected. Maybe they should have included extraterrestrial and non-human (or even non-animal) forms of life in the count for it to be considered noteworthy?
Comment 31 Steven Walling 2014-04-06 23:22:32 UTC
(In reply to Nemo from comment #30)
> From http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075721.html
> > TL;DR: one user saying they chose to download the fonts in question is not
> > the same thing as a report that a significant minority might have them.
> 
> Please establish a number of scapegoats and guinea pigs that one has to
> sacrifice for Steven Walling the god of fonts to accept that something is
> going to go bad. AFAICS, people had anticipated that several billions of
> world inhabitants (those speaking non-Latin script languages) were going to
> be almost surely negatively affected. Maybe they should have included
> extraterrestrial and non-human (or even non-animal) forms of life in the
> count for it to be considered noteworthy?

Nemo, 

We actually did release two different followup versions of the body copy settings after Patrick's comments. It was in large part due to feedback from Wikimedians like him. The fact that now we encountered a new issue where lots of users unintentionally get a font that does not render acceptably well is unfortunate, and we're responding as fast as we can.
Comment 32 Gerrit Notification Bot 2014-04-07 19:56:49 UTC
Change 124387 had a related patch set uploaded by Jdlrobson:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124387
Comment 33 Gerrit Notification Bot 2014-04-07 21:23:16 UTC
Change 124387 merged by jenkins-bot:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124387
Comment 34 Gerrit Notification Bot 2014-04-07 22:15:58 UTC
Change 124475 had a related patch set uploaded by Odder:
Remove unfree fonts from font stack

https://gerrit.wikimedia.org/r/124475
Comment 35 Gerrit Notification Bot 2014-04-07 22:49:03 UTC
Change 124486 had a related patch set uploaded by Catrope:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124486
Comment 36 Gerrit Notification Bot 2014-04-07 22:49:53 UTC
Change 124487 had a related patch set uploaded by Catrope:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124487
Comment 37 Gerrit Notification Bot 2014-04-07 23:24:06 UTC
Change 124487 merged by jenkins-bot:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124487
Comment 38 Gerrit Notification Bot 2014-04-07 23:28:01 UTC
Change 124486 merged by Catrope:
Remove troublesome fonts from font stack

https://gerrit.wikimedia.org/r/124486
Comment 39 Steven Walling 2014-04-08 00:01:46 UTC
Fix merged and deployed.
Comment 40 Matthew Flaschen 2014-04-08 17:24:43 UTC
(In reply to Jared Zimmerman (WMF) from comment #0)
> More details here https://twitter.com/mrtnclzd/status/451926785672753152

In the future, please explain the issue in the bug report, like bug 63591.  It can be a concise explanation, but links are indirect (and sometimes require scrolling around before you get the idea) and go dead, so it's better to have something clear here.
Comment 41 Gerrit Notification Bot 2014-04-11 18:41:52 UTC
Change 124475 merged by Bartosz Dziewoński:
Revert font stack to be just sans-serif

https://gerrit.wikimedia.org/r/124475
Comment 42 Gerrit Notification Bot 2014-04-11 19:15:01 UTC
Change 125447 had a related patch set uploaded by Bartosz Dziewoński:
Revert font stack to be just sans-serif

https://gerrit.wikimedia.org/r/125447
Comment 43 Bartosz Dziewoński 2014-04-11 19:17:50 UTC
These patches are probably not very relevant to this bug, actually. Sorry.
Comment 44 Gerrit Notification Bot 2014-04-14 23:13:30 UTC
Change 125447 merged by jenkins-bot:
Revert body font stack to be just sans-serif

https://gerrit.wikimedia.org/r/125447

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links