mrtnclzd wrote:

Windows 7 Professional SP1, Chrome: http://i.imgur.com/9QD1ujH.png
Windows 7 Ultimate SP1, Chrome: http://i.imgur.com/FvGdfln.png

• Bug 63511 has been marked as a duplicate of this bug. ***

Do we know what version of Chrome? I'm struggling to replicate on browserstack.com

mrtnclzd wrote:

I don't think it's the browser, both images are running 33.0.1750.154 m.

mrtnclzd wrote:

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

swalling wrote:

I am pretty sure this issue is being caused by Liberation Sans. Is it the case you have it installed Martin?

Could be related to browser zooming and the fact we now use ems ... https://twitter.com/TeaJunkie1/status/452230220876369920

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.

mrtnclzd wrote:

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

mrtnclzd wrote:

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

mrtnclzd wrote:

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.

swalling wrote:

Thanks very much for the assistance Martin.

• Bug 63591 has been marked as a duplicate of this bug. ***

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?

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

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?

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.

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.

swalling wrote:

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

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.

swalling wrote:

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

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

(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.)

(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

swalling wrote:

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

(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%.

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?

(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

swalling wrote:

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

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?

swalling wrote:

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

Change 124387 had a related patch set uploaded by Jdlrobson:
Remove troublesome fonts from font stack

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

Change 124387 merged by jenkins-bot:
Remove troublesome fonts from font stack

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

Change 124475 had a related patch set uploaded by Odder:
Remove unfree fonts from font stack

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

Change 124486 had a related patch set uploaded by Catrope:
Remove troublesome fonts from font stack

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

Change 124487 had a related patch set uploaded by Catrope:
Remove troublesome fonts from font stack

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

Change 124487 merged by jenkins-bot:
Remove troublesome fonts from font stack

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

Change 124486 merged by Catrope:
Remove troublesome fonts from font stack

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

swalling wrote:

Fix merged and deployed.

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

Change 124475 merged by Bartosz Dziewoński:
Revert font stack to be just sans-serif

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

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

These patches are probably not very relevant to this bug, actually. Sorry.

Change 125447 merged by jenkins-bot:
Revert body font stack to be just sans-serif

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

Is this still a problem?