Brad Jorsch (Anomie) wrote:

On Sat, Oct 26, 2013 at 12:52 PM, MZMcBride z@mzmcbride.com wrote:

...

There's an open question in my mind as to what constitutes a "non-free font,"

In this context, I mean "non-free" in the context of libre rather than gratis.[1]

Right. The "libre" part is what I consider a legal issue, though I think I understand more clearly now that you're talking about technical policy here.

There are a number of fonts that can be downloaded for free (gratis) but are under terms along the lines of a CC -NC or -ND license, and there are more that are distributed with various popular operating systems so many people already have them for "free" in the loosest sense. I'm not counting these as free here.

Thank you for clarifying this point. It might be helpful to have a list of gratis/libre fonts and a list of gratis/non-libre fonts, if such lists don't exist already.

As far as I know, MediaWiki (core) has historically preferred to specify nothing more than sans-serif. There now seems to be a trend away from this.

https://www.wikimedia.org/wiki/Guiding_principles#Freedom_and_open_source is a citation for my earlier claim that Wikimedia prefers free to non-free. Nemo_bis pointed me toward this related discussion as well: http://lists.wikimedia.org/pipermail/design/2012-October/000191.html.

MZMcBride

On Oct 27, 2013 4:19 AM, "MZMcBride" z@mzmcbride.com wrote:

Brad Jorsch (Anomie) wrote:

...

On Sat, Oct 26, 2013 at 12:52 PM, MZMcBride z@mzmcbride.com wrote:

...

There's an open question in my mind as to what constitutes a "non-free font,"

In this context, I mean "non-free" in the context of libre rather than gratis.[1]

Right. The "libre" part is what I consider a legal issue, though I think I understand more clearly now that you're talking about technical policy here.

...

There are a number of fonts that can be downloaded for free (gratis) but are under terms along the lines of a CC -NC or -ND license, and there are more that are distributed with various popular operating systems so many people already have them for "free" in the loosest sense. I'm not counting these as free here.

Thank you for clarifying this point. It might be helpful to have a list of gratis/libre fonts and a list of gratis/non-libre fonts, if such lists don't exist already.

I started building a list a while ago, for similar reasons, limited to fonts being used on the projects.

https://meta.wikimedia.org/wiki/Fonts

-- John

Le 26/10/13 20:00, Siebrand Mazeland (WMF) a écrit :

One instance remains in the header "monospace hack, could probably be changed to "monospace, monospace"". Can you please elaborate?

Have a look at docs/uidesign/monospace.html which exposes the monospace issue.

If you add another font after monospace, the browsers would no more consider it a monospace font and use the default font size for serif/sans-serif font, thus the monospace text ends up having a size consistent with the rest of the document.

font-family: monospace, DOESNOTEXISTREALLY;

That does the trick.

I have created the HTML doc following up a discussion with Erwin Dokter on bug 33496: https://bugzilla.wikimedia.org/show_bug.cgi?id=33496

On Sat, Oct 26, 2013 at 7:57 PM, Erwin Dokter erwin@darcoury.nl wrote:

This is completly a non-issue. CSS Font stacks merely *refer* to a font already installed (and paid for) on a reader's computer. There are no legal issues arising form this whatsoever.

You missed the point. The issue is ideological, not legal.

When it comes to selecting fonts, it is natural in web design to first refer to the most commonly installed fonts available. If you were to specify only free fonts, they would have no effect on the 99% of our reader's computers, because they don't have those font installed to begin with. In short, preferring free fonts in a font stack is utterly pointless.

Surely it's closer to 98%.[1] ;(

Actually, I've seen plenty of sites that specify fonts with lesser expected penetration first, usually fonts distributed with Mac OSes but not Windows.

The drawback to specifying the non-free font first is that those of us who have both still get the non-free font.

[1]: Non-Android Linux has a bit over 2%, according to http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm

On Oct 26, 2013, at 2:31 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:

That said, my personal preference would be for us to keep our font neutrality and not declare anything other than 'serif' and 'sans-serif', but I'm open to listening to other people's arguments.

rgree++

While I see the value in specifying font stacks that are arguably “prettier” I also don’t think it’s worth giving up our principles for it.

--- Brandon Harris, Senior Designer, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

On 27-10-2013 11:14, Erwin Dokter wrote:

And since we're sharing links... I also have a (non-finished) essay on typography where you can see the most prevalant system and open fonts together at http://en.wikipedia.org/wiki/WP:TYPO.

Argh... that should have been http://en.wikipedia.org/wiki/WP:TYPE.

Met vriendelijke groet,

On 27-10-2013 11:19, David Gerard wrote:

The problem with listing the nonfree fonts first is that you'll end up designing *for* the nonfree fonts, and come up with stuff that just happens to look like garbage without them.

I strive for maximum coverage using both regular *and* free fonts to maximize coverage. That usually means using the system fonts first (but not always). It is really just a matter of maximizing use of what's out there.

Met vriendelijke groet,

As one that started of participated in this discussion in many "back corners"...

On 10/27/2013 09:50 AM, Chad wrote:

Our ideologies are far more important than typography.

We bet on free licenses for all the content and software we produce, even if sometimes potentially superior "free as in beer" alternatives are available. We systematically bet on free as in freedom content, file formats and programs not only because they are free, but also because by using them we contribute to their promotion, consolidation and success.

I personally don't see a reason to sacrifice this consistency in order to use and advertise a proprietary typeface because it looks better today in certain displays.

I agree with Kaldari and Brandon earlier: serif, sans-serif, monospace.

+1.

And if we want to specify any fonts in our works, they should be free. Why would we need to start our own foundry from scratch? There are many free typefaces, more and better every year. Google has done a big investment and as a result Android ships with free fonts only, and they host a huge repository of free webfonts. Even Adobe publishes pretty decent free fonts these days. The trend is clear, we are not in 2003 anymore. I don't see why we have to go in a different direction instead of supporting the trend of free fonts explicitly or, at least, stay neutral (serif, sans-serif, monospace).

On 27 October 2013 19:37, Steven Walling steven.walling@gmail.com wrote:

We have never and will never ship a proprietary font to users who do not have one installed, and I think we should maybe make that an official policy if it isn't already. However, specifying better font families for users that already have them can and has improved the experience for millions of readers. Wikimedia projects and MediaWiki seem like dinosaurs, even within the FOSS community, by enforcing a standard of using whatever random sans serif a user has, and nothing more.

OK ... and the tradeoff of the designer assuming the non-free font, and it just happening to look like garbage with any free font?

- d.

On 27 October 2013 19:47, Steven Walling steven.walling@gmail.com wrote:

On Sun, Oct 27, 2013 at 12:44 PM, David Gerard dgerard@gmail.com wrote:

...

OK ... and the tradeoff of the designer assuming the non-free font, and it just happening to look like garbage with any free font?

David, you should ask the designers why they chose the stack in VectorBeta, rather than assuming they ignored free/open platforms. If you look, you'll notice that they took the time on MobileFrontEnd and in VectorBeta to examine what fonts were most widely available and look good on free platforms, and specify them.

That's ... precisely evading the question.

- d.

On Sun, Oct 27, 2013 at 3:37 PM, Steven Walling steven.walling@gmail.comwrote:

1. The 'VectorBeta' change is to create an _opt-in_ beta for typography

changes, as part of the release of BetaFeatures extension. We'd only be providing something to users who want to try this font stack. It's a choice they get to make, and in that sense I think it's a little wrong for us to dictate anything based solely on ideology.

If you need to install an extension to enable the typography, then why is it even in core in the first place?

Also, I really hope there was no malicious intention behind this change. Because the originally uploaded patch set (i.e., PS1, or the patch that people initially get an email about) was completely different from the patch that was merged. Changing the subject of patches so suddenly and drastically is quick and dirty move to hide changes from people who subscribe to the new patchset feed. Please don't do that again in the future.

*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science

On 27-10-2013 20:37, Steven Walling wrote:

Many FOSS communities have dealt with the trade off between great-looking fonts and freedom by commissioning foundries to get their own free fonts. See also: Ubuntu, Android, and more. I've talked to the design team about this idea, including perhaps getting a foundry to donate a unique font stack in exchange for the publicity they'd get.

Those FOSS communities distribute software such as operating systems; you cannot compare them to websites like Wikipedia. The MediaWiki software generate those websites. So I think the comparison is not acurate.

Whould MediaWiki commision it's own font? No; too expensive/time consuming. Could we possibly use an existing free (web) font? Possibly, but it will cost extra bandwidth serving them. That leaves using fonts that are available on readers' systems.

Whoever said that typography is not important, is totally wrong; it is an inseparable part of web design. Avoiding proprietary fonts is just as pointless as avoiding proprietary web browsers.

Met vriendelijke groet,

On Sun, Oct 27, 2013 at 4:23 PM, MZMcBride z@mzmcbride.com wrote:

Steven Walling wrote:

...

You're leaving out two key facts here:

1. The 'VectorBeta' change is to create an _opt-in_ beta for typography

changes, as part of the release of BetaFeatures extension. We'd only be providing something to users who want to try this font stack. It's a choice they get to make, and in that sense I think it's a little wrong for us to dictate anything based solely on ideology.

Why is this a key fact? Will we soon be allowing users to opt in to Facebook "like" buttons, Google Analytics, and "all rights reserved" copyright for their contributions? I don't think making something optional somehow makes it a better idea.

In the case of MediaWiki, by using sans-serif, aren't we specifically not dictating to users what to use? I don't follow your logic here.

Brad's original email failed to point out that the VectorBeta patch isn't a "direction we're going in" for all of Vector or all of MediaWiki. It's an opt-in preference for users on Wikimedia projects, where the BetaFeatures extension is to be deployed. The patch he brought up is essentially no different than a skin like Cologne Blue setting a different font stack, for users who choose it.

...

2. This beta font stack for desktop is based primarily on our mobile

font stack, which is already the default seen by all mobile readers and editors on Wikimedia projects. People keep saying "traditionally" we have not specified a real font stack, but the truth is we abandoned that tradition going back to October 2012:

https://blog.wikimedia.org/2012/10/24/wikipedia-mobile-gets-a-new-look/

This makes no sense to me. Why should we be following mobile's trends? The mobile site currently intentionally disables anonymous editing (a direct violation of core Wikimedia principles). It also contains a number of other questionable design decisions, much as its predecessors did.

Would you say we abandoned the tradition of allowing anonymous editing simply because of the mobile team's questionable design decision? Again, I have difficulty following your logic here.

I think when people say "traditionally," they mean "with the exception of the mobile team, which doesn't seem to care about adhering to Wikimedia or MediaWiki design philosophies." Yes, you can find plenty of other examples of the mobile team doing things like this, but that hardly seems like a good reason to import those choices into desktop.

Sorry if you don't like MobileFrontend's design, but it's clearly not an opinion universally shared among readers and editors on the mobile version of Wikimedia projects. It's nearing 20% of our overall traffic every month, and growing like weeds.[1] Thousands of people a month are editing via mobile too. Neither of those things would be happening if your logic was correct, and their divergent choices from the rest of MediaWiki were really so awful for users. The way MobileFrontend is designed is highly effective for people on mobile devices, and I think there's no reason to block an experiment to let people opt-in to its style of typography on desktop.

1. http://reportcard.wmflabs.org/graphs/pageviews_mobile

On Sun, Oct 27, 2013 at 7:49 PM, Steven Walling steven.walling@gmail.com wrote:

On Sun, Oct 27, 2013 at 4:23 PM, MZMcBride z@mzmcbride.com wrote:

...

Steven Walling wrote:

...

You're leaving out two key facts here:

1. The 'VectorBeta' change is to create an _opt-in_ beta for typography

changes, as part of the release of BetaFeatures extension. We'd only be providing something to users who want to try this font stack. It's a choice they get to make, and in that sense I think it's a little wrong for us to dictate anything based solely on ideology.

Why is this a key fact? Will we soon be allowing users to opt in to Facebook "like" buttons, Google Analytics, and "all rights reserved" copyright for their contributions? I don't think making something optional somehow makes it a better idea.

In the case of MediaWiki, by using sans-serif, aren't we specifically not dictating to users what to use? I don't follow your logic here.

Brad's original email failed to point out that the VectorBeta patch isn't a "direction we're going in" for all of Vector or all of MediaWiki. It's an opt-in preference for users on Wikimedia projects, where the BetaFeatures extension is to be deployed. The patch he brought up is essentially no different than a skin like Cologne Blue setting a different font stack, for users who choose it.

Where I come from, "beta" does mean "this is the direction we're intending to go in, subject to testing and feedback before it's made an official release". I'm not aware of anyone who uses a definition of "this is an option, that we're always going to keep as a non-default option".

On Mon, Oct 28, 2013 at 10:20 AM, Erik Moeller erik@wikimedia.org wrote:

Prioritizing freely licensed fonts while also explicitly naming the preferred non-free fonts seems like an easy fix.

Again, this is already done for us by fontconfig when presented with the ASCII sequence "H e l v e t i c a". There's no reason for our font stack to do it unless some freely-licensed font looks better than the non-free font; also it will work against the brave and few who follow steps like http://www.binarytides.com/gorgeous-looking-fonts-ubuntu-linux/ to adjust the appearance of those well-known names.

-- =S Page Features engineer

On Mon, Oct 28, 2013 at 1:20 PM, Erik Moeller erik@wikimedia.org wrote:

Prioritizing freely licensed fonts while also explicitly naming the preferred non-free fonts seems like an easy fix.

I'm sad to see that they decided to go in the entirely opposite direction, removing all mention of free fonts entirely in their font stack,[1] and are planning on forcing the non-free fonts on all Vector users (not just those opted into the "beta") sometime in the week of February 24.[2]

[1]: https://gerrit.wikimedia.org/r/#/c/108155/ [2]: https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=prev&a...

And surely, before WMF/"MediaWiki" tell the world that no free fonts of good quality exist, there will be some document detailing exactly why and based on what arguments/data/research the numerous free alternatives were all rejected? Free fonts developers are an invaluable resource for serving Wikimedia projects' content in all languages, we shouldn't carelessly slap them in their face.

Nemo

On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier greg@wikimedia.org wrote:

<quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100"> > And surely, before WMF/"MediaWiki" tell the world that no free fonts > of good quality exist, there will be some document detailing exactly > why and based on what arguments/data/research the numerous free > alternatives were all rejected? Free fonts developers are an > invaluable resource for serving Wikimedia projects' content in all > languages, we shouldn't carelessly slap them in their face.

I just skimmed the entire thread again, and yes, this has been requested a few times but no one from the WMF Design team has responded with that analysis (or if would respond with an analysis). The first time it was requested the person was told to ask the Design list, then the next message CC'd the design list, but no response on that point.

I don't see much on https://www.mediawiki.org/wiki/Typography_refresh nor it's talk page. Nor https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography

There wasn't an answer because the question is a fundamental misunderstanding of the way CSS works and options that are within our reach. The question isn't "are there good free fonts?" the question is "can we deliver good free fonts to all users?". I'll try to help the UX team document the answer better.

Frankly, I think there has been a large degree of intransigence on both sides. The free font advocates have refused to identify the fonts that they want to be considered and why they should be considered other than the fact that they are free, and the designers have refused to take any initiative on considering free fonts. The free fonts that I know have been considered are: * DejaVu Serif. Conclusion: Widely installed, but horribly ugly and looks nothing like the style desired by the designers. * Nimbus Roman No9 L. Conclusion: Basically a clone of Times. Most Linux systems map Times to Nimbus Roman No9 L, so there is no advantage to specifying "Nimbus Roman No9 L" rather than "Times" (which also maps to fonts on Windows and Mac). * Linux Libertine. Conclusion: A well-designed free font that matches the look of the Wikipedia wordmark. Unfortunately, it is not installed by default on any systems (as far as anyone knows) but is bundled with LibreOffice as an application font. If MediaWiki were using webfonts, this would likely be the serif font of choice rather than Georgia, but since we are relying on pre-installed fonts, it would be rather pointless to list it. * Liberation Sans. Conclusion: Essentially a free substitute for Arial. Like Nimbus Roman, there is no advantage to specifying "Liberation Sans" instead of "Arial" (which is at the bottom of the sans-serif stack) since Linux systems will map to Liberation Sans anyway, while other systems will apply Arial.

As to proving the quality of Georgia and Helvetica Neue, I don't think the designers have done that, but I also haven't seen any evidence from the free font advocates concerning the quality of any free fonts. So in my view, both sides of the debate have been delinquent.

Ryan Kaldari

On Sat, Feb 15, 2014 at 4:16 PM, Greg Grossmeier greg@wikimedia.org wrote:

<quote name="Steven Walling" date="2014-02-15" time="16:08:41 -0800"> > On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier <greg@wikimedia.org> wrote: > > > <quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100"> > > > And surely, before WMF/"MediaWiki" tell the world that no free fonts > > > of good quality exist, there will be some document detailing exactly > > > why and based on what arguments/data/research the numerous free > > > alternatives were all rejected? Free fonts developers are an > > > invaluable resource for serving Wikimedia projects' content in all > > > languages, we shouldn't carelessly slap them in their face. > > > > I just skimmed the entire thread again, and yes, this has been requested > > a few times but no one from the WMF Design team has responded with that > > analysis (or if would respond with an analysis). The first time it was > > requested the person was told to ask the Design list, then the next > > message CC'd the design list, but no response on that point. > > > > I don't see much on https://www.mediawiki.org/wiki/Typography_refresh > > nor it's talk page. Nor > > https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography > > > > There wasn't an answer because the question is a fundamental > misunderstanding of the way CSS works and options that are within our > reach. The question isn't "are there good free fonts?" the question is "can > we deliver good free fonts to all users?". I'll try to help the UX team > document the answer better.

Thanks.

I may be part of the misunderstanding-of-how-things-work-in-font-land contingent. Advice/clarity appreciated.

Greg

-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

---

Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design

Ryan Kaldari, 16/02/2014 06:54:

Now that I've blamed everyone except for myself, I would like to suggest that we stop pointing fingers and get down to brass tacks.

Brad's email was a bit caustic but IMHO it wasn't pointing fingers, unlike yours (though you helpfully pointed fingers towards everyone). ;-)

My question for both the designers and the free font advocates is: Are there any free fonts that are...

1. widely installed (at least on Linux systems)
2. easily readable and not distractingly ugly
3. would not be mapped to by the existing stack anyway (i.e. are not

simply clones or substitutes for popular commercial fonts)

I'm sorry but this question to "the free font advocates" does not make sense and I refuse to accept it, for two reasons: 1) is not a given or an immutable law of physics, it's the designers' job to assess: if you really care for a specific font you serve it; if you don't want to serve fonts, then design must adapt to availability and not the opposite; 2) is again the designers' job, I have no idea how one assesses "easily readable"* and I'd like us to banish personal opinions including adjectives like "strange" or "ugly" from any and all design decision;** moreover, if feedback had ever been desired on font choices, we would have a document explaining what this mythical "style desired by the designers" actually is, other than the superlunar ideal no human MediaWiki commentator can sense and comment.

So again, I'm waiting for documentation. Whoever refrains from publishing documentation, research, design documents etc. as soon as they are produced prevents iterations and feedback from happening and hence takes full personal responsibility of whatever outcome of the process, begging to be personally blamed.

Nemo

(*) In my very biased and personal experience of a Latin alphabet languages reader, "readable" equals "serif" so that I can tell I from l etc., and DejaVu serif is the most beautiful font ever because it covers so many characters. (**) I'm really hearing them too often. They are suppressors of discussion/rational discourse and polarise discussions unnecessarily. Cf. https://en.wikipedia.org/wiki/WP:IDONTLIKEIT.

On 02/15/2014 09:54 PM, Ryan Kaldari wrote:

Now that I've blamed everyone except for myself, I would like to suggest that we stop pointing fingers and get down to brass tacks.

My question for both the designers and the free font advocates is: Are there any free fonts that are...

1. widely installed (at least on Linux systems)
2. easily readable and not distractingly ugly
3. would not be mapped to by the existing stack anyway (i.e. are not simply

clones or substitutes for popular commercial fonts)

I have been very happy with the crisp rendering and screen-optimized shape of DejaVu Sans selected as the default sans-serif font on Debian Linux. At a given size it is about as readable as Verdana while looking (to my eyes at least) more elegant.

DejaVu Sans has a fairly good unicode coverage by itself, and in my limited experience fontconfig picks good other fonts for rare scripts. I have not seen any tofu on Linux in a long time.

The rendering of the font refresh beta on my Linux box seems to be Helvetica without subpixel rendering (blurry), which is a real regression from the status quo.

I am not entirely sure that there is actually a problem to solve on an average Linux desktop installation, but am willing to be convinced otherwise with a documentation of the issues encountered.

Some of the limitations you are trying to address seem to be platform-specific. Could we address those in a targeted way without making things worse for other platforms?

Gabriel

On Sat, Feb 15, 2014 at 3:59 PM, Greg Grossmeier greg@wikimedia.org wrote:

<quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100"> > And surely, before WMF/"MediaWiki" tell the world that no free fonts > of good quality exist, there will be some document detailing exactly > why and based on what arguments/data/research the numerous free > alternatives were all rejected? Free fonts developers are an > invaluable resource for serving Wikimedia projects' content in all > languages, we shouldn't carelessly slap them in their face.

I just skimmed the entire thread again, and yes, this has been requested a few times but no one from the WMF Design team has responded with that analysis (or if would respond with an analysis). The first time it was requested the person was told to ask the Design list, then the next message CC'd the design list, but no response on that point.

I don't see much on https://www.mediawiki.org/wiki/Typography_refresh nor it's talk page. Nor https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography

cc'ing the Design list :)

Update on this: after discussing with Greg, Jared, etc. I've edited wikitech Deployments calendar to reflect a longer term goal of mid to late March at the earliest.

The calls from Greg, Kaldari, Nemo and others for better documentation are 100% correct, and it's something we should do before we move to merge anything from the typography refresh in to Vector proper. There's a better FAQ and more in development by the design team, but getting that out and properly translated in just a week is not realistic. Overall the continued discussion on Wikitech-l suggestions to me that doing this by the 27th would be a rush job.

Note that there was a small update to the feature on Friday, which removed the max-width restriction and tweaked some padding. I'd encourage anyone who hasn't tried the beta feature in a few weeks to give it another shot. We'll update Typography Refresh and the accompanying Talk page on mediawiki.org accordingly.

Thanks,

On Mon, Feb 17, 2014 at 12:59 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:

There was also a small addition to that feature, which concerns the ToC styling, which has had NO time to garner feedback yet, so I think postponing is a good idea. Also a good pass of the feedback page seems a requirement for any deploy if you ask me :D

The TOC style is actually not new as of Friday (see: https://gerrit.wikimedia.org/r/#/c/108155/), and rolled out to most Wikimedia sites on Feb 6th. I think it's just that enough MediaWiki insiders disliked the max-width that they stopped using the beta feature, and haven't seen the updates since then. ;)

Brad since you work for the for the foundation and seem to have a lot of expertise in this area and seem to have been one of the more vocal supporters of free fonts have you reached out to your work colleagues over video conferencing or similar to understand the problems being hit and helped them work through them? Email doesn't seem to have been an effective method of communication in this situation as you have pointed out. Maybe you can help with documenting these issues and helping people like yourself understand the problems and why this change was reverted?

Many people actually complained on the talk page about the rendering of free fonts. Should we also ignore them?

On a side note software is never final. It is not like we are transitioning from a free font to a non free font.

Just my 2 cents on this subject. (written as a volunteer not a WMF employee) On Sat, Feb 15, 2014 at 4:31 PM, Ryan Kaldari rkaldari@wikimedia.orgwrote:

That's not quite accurate. The new font stack is based on feedback from Linux users who preferred that we take advantage of the font-mapping built into Linux rather than trying to guess arbitrary fonts that may or may not be installed on their machine.

And ignoring the feedback from users who would rather see free fonts explicitly supported?

"Helvetica", "Times", etc. are not non-free software, they are names of well-established (non-copyrighted) typefaces

Considering that typefaces aren't eligible for copyright in the US,[1] that's not saying anything.

[1]: https://en.wikipedia.org/wiki/Intellectual_property_protection_of_typefaces

We're trying to balance the requirements of the designers

I've been seeing a trend lately where the "requirements of the designers" is brought up a lot in response to complaints about proposed changes. Explanations as to what exactly these requirements usually have to be repeatedly requested, and reasons why these requirements should override other requirements are seldom given.

The two exceptions to this are the tops of the stacks:

So it's "Whenever possible, you get these non-free fonts we like. Then we throw in some supposedly-generic names used by prominent non-free fonts with the platitude that they're often mapped to free fonts on Linux".

On Sun, Feb 16, 2014 at 12:07 AM, Ryan Kaldari <rkaldari@wikimedia.org

wrote:

The free font advocates have refused to identify the fonts that they want to be considered and why they should be considered other than the fact that they are free,

"the fact that they are free" specifically is what we want to be considered.

As for specific fonts, my knowledge of fonts extends to "serif", "sans-serif", and "monospace".

• DejaVu Serif. Conclusion: Widely installed, but horribly ugly

{{citation needed}}. Sounds like someone's peronsal opinion to me.

I just checked,[2] and it turns out DejaVu Sans is what I've been reading Wikipedia in all these years. Seems far from "horribly ugly" to me. Nicer than Arial used in Gmail where "I" and "l" look the same, or the font that my system uses as a fallback for Helvetica ("TeX Gyre Heros").

[2]: In Firefox: Tools → Web Developer → Inspector, then choose Fonts in the box on the right.

and looks nothing like the style desired by the designers.

And why is this an overriding concern? I could as well state the designers should desire a different style.

* Nimbus Roman No9 L. Conclusion: Basically a clone of Times. Most Linux

systems map Times to Nimbus Roman No9 L, so there is no advantage to specifying "Nimbus Roman No9 L" rather than "Times" (which also maps to fonts on Windows and Mac).

OTOH, there's no disadvantage to specifying Nimbus Roman No9 L with "Times" as a fallback for Windows and Mac users.

• Linux Libertine. Conclusion: A well-designed free font that matches the

look of the Wikipedia wordmark. Unfortunately, it is not installed by default on any systems (as far as anyone knows)

Why does this matter? If Libertine is a good font, why not use it and fall back to other choices for people who don't have it?

• Liberation Sans. Conclusion: Essentially a free substitute for Arial.

Like Nimbus Roman, there is no advantage to specifying "Liberation Sans" instead of "Arial" (which is at the bottom of the sans-serif stack) since Linux systems will map to Liberation Sans anyway, while other systems will apply Arial.

Again, there's no also disadvantage to specifying Liberation Sans with "Arial" as a fallback for unfortunate users who only have non-free fonts distributed with their OS. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Feb 16, 2014 2:04 PM, "Jon Robson" jdlrobson@gmail.com wrote:

Brad since you work for the for the foundation and seem to have a lot of expertise in this area and seem to have been one of the more vocal supporters of free fonts have you reached out to your work colleagues over video conferencing or similar to understand the problems being hit and helped them work through them? Email doesn't seem to have been an

effective

method of communication in this situation as you have pointed out. Maybe you can help with documenting these issues and helping people like

yourself

understand the problems and why this change was reverted?

I've seen setiment like this (discuss in person, in hangout, or otherwise privately) pop up recently (e.g on [1]). I think attitudes like that are a real problem. Supposedly we are an open community. People should be entirely prepared to explain their reasoning for doing anything on a public mailing list no matter if the request comes from a wmf staffer like Brad, or if it comes from somebody you have never heard of before. In fact i would argue that the criteria and results of evaluations should be public on the wiki from the get go, without anyone even asking for it.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=57659

On 16 February 2014 22:28, Steven Walling steven.walling@gmail.com wrote:

or David's suspicions about a growing trend of preferring non-free software :P

No, I'm not in fact joking.

- d.

<quote name="Brian Wolff" date="2014-02-16" time="18:00:29 -0400">

On Feb 16, 2014 2:04 PM, "Jon Robson" jdlrobson@gmail.com wrote:

...

Brad since you work for the for the foundation and seem to have a lot of expertise in this area and seem to have been one of the more vocal supporters of free fonts have you reached out to your work colleagues over video conferencing or similar to understand the problems being hit and helped them work through them? Email doesn't seem to have been an

effective

...

method of communication in this situation as you have pointed out. Maybe you can help with documenting these issues and helping people like

yourself

...

understand the problems and why this change was reverted?

I've seen setiment like this (discuss in person, in hangout, or otherwise privately) pop up recently (e.g on [1]). I think attitudes like that are a real problem. Supposedly we are an open community. People should be entirely prepared to explain their reasoning for doing anything on a public mailing list no matter if the request comes from a wmf staffer like Brad, or if it comes from somebody you have never heard of before. In fact i would argue that the criteria and results of evaluations should be public on the wiki from the get go, without anyone even asking for it.

See also: The general rule among many engineering departments at WMF is "If it didn't happen on the list (or somewhere similarly public and indexable) it didn't happen."

The team I most recently heard champion that rule was the Mobile Team.

Greg

On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier greg@wikimedia.org wrote:

See also: The general rule among many engineering departments at WMF is "If it didn't happen on the list (or somewhere similarly public and indexable) it didn't happen."

Wikitech is great for discussing things with a wider audience especially where we need to seek opinions of developers outside the staff. But most decisions people make are documented on a wiki, Bugzilla, and/or their preferred project management tool. A mailing list is quite bad at reaching a consensus decision on something, as evidenced by the fact that we hold RFCs on a wiki, and not here.

No one is suggesting that we should make all decisions via teleconferencing. If you read Jon's comment with good faith, he obviously wants to reach common ground with Brad on a contentious issue, and suggested using a medium that is different than what we've tried already. Brad has brought this up repeatedly on the list and Talk:Typography Refresh, discussing this with both end users who disagreed and fellow staff members. Little apparent progress has been made in reaching consensus. Jon's trying to be respectful and reach common ground with a coworker. I don't think anyone should be taken to task for such behavior, not when (as you say) Jon's clearly been part of a team that has pushed for better documentation of decisions than just in-office face to face meetings.

In short: mountain out of a mole hill. Don't assume people don't care about public discussion because they want to have a 1-1 with someone whose opinion they think is important.

On Feb 16, 2014 4:01 PM, "Steven Walling" steven.walling@gmail.com wrote:

On Sun, Feb 16, 2014 at 3:36 PM, Greg Grossmeier greg@wikimedia.org

wrote:

...

See also: The general rule among many engineering departments at WMF is "If it didn't happen on the list (or somewhere similarly public and indexable) it didn't happen."

Wikitech is great for discussing things with a wider audience especially where we need to seek opinions of developers outside the staff. But most decisions people make are documented on a wiki, Bugzilla, and/or their preferred project management tool. A mailing list is quite bad at reaching a consensus decision on something, as evidenced by the fact that we hold RFCs on a wiki, and not here.

No one is suggesting that we should make all decisions via teleconferencing.

And I'm not saying the opposite. I'm just referring to the communication of those decisions (see subject ;)). The end reasoning and decision part (at least).

Tangentially, I very much disagree with the sentiment that email = bad for group discussion. There are so many counter examples where it is good for discussion, and notably in technical discussions where details/quoting is important.

End rant :)

Greg (from phone)

On 10/27/2013 03:37 PM, Steven Walling wrote:

Many FOSS communities have dealt with the trade off between great-looking fonts and freedom by commissioning foundries to get their own free fonts. See also: Ubuntu, Android, and more. I've talked to the design team about this idea, including perhaps getting a foundry to donate a unique font stack in exchange for the publicity they'd get.

Do we really need our own, or are there already quality free fonts we can list? Has the design team taken a good look at the existing free fonts?

My general position is that it is not a violation of our principles to list a proprietary font in the stack. However, we should never *distribute* such a font.

I would prefer that free fonts appear first, and that is more workable if we can find good free fonts that suit our design needs. We should also ensure that the interface does not look worse in the future than it does today, when using free fonts.

Also, remember that font-matchers may substitute a free font when they are given a proprietary font name.

Matt Flaschen

CCing design

On 28/10/13 02:32, Tim Starling wrote:

There is the separate issue that on my Linux laptop, Nimbus Sans L looks worse than the font my browser will choose for sans-serif. That is because I have customised Firefox to use the Ubuntu font for sans-serif, which is very readable. I find all the Arial clones to be too narrow for comfortable reading.

-- Tim Starling

That reminds me of something of a point folks tend to forget - generally the system font is chosen in part just because it renders well with the system font renderer, so overriding that can have unexpected side effects in terms of legibility. How the same font (or its clone) renders can vary significantly across systems, so even if a font type looks good on a mac, for instance, it may look bad on windows or even be downright unreadable on linux with a fontconfig which simply wasn't written with the specific font in mind.

I found this to be a good part why arial was so damn unreadable on my linux setup, for instance, though even with it rendering properly now it's still narrower than I find comfortable as well. Perhaps this is just because I'm used to wider, but going against what people are used to (and thus have effectively trained their brains upon), or especially what they might have specifically customised (in particular large or dyslexic fonts come to mind as a specific usability issue here), also seems like an odd move.

And yes, I know it's a standard move that websites tend to make. It's still odd, and I can't say I like that folks are trying to take mediawiki/wikimedia in a similar direction, even without the question of whether or not the specifics are free or not.

On Mon, Oct 28, 2013 at 01:32:30PM +1100, Tim Starling wrote:

Yes, we should prefer to use free software. We should also strive to ensure that our support for users on non-free platforms is optimal, as long as that doesn't negatively impact on users of free platforms. So I don't think it is a problem to specify non-free fonts in font lists.

It's a bit more complicated than that. Linux distros ship with fontconfig (which is used by Cairo, which in turn is used by at least Firefox). Fontconfig aliases fonts via a set of rules and the default rules map popular non-free fonts to their free metric equivalents, or generics. e.g.

$ fc-match Helvetica n019003l.pfb: "Nimbus Sans L" "Regular"

$ fc-match Arial LiberationSans-Regular.ttf: "Liberation Sans" "Regular"

$ fc-match "Courier New" LiberationMono-Regular.ttf: "Liberation Mono" "Regular"

$ fc-match INVALID DejaVuSans.ttf: "DejaVu Sans" "Book"

This effectively means that, for Linux, having the free fonts at the end of the CSS font selection is probably[1] a no-op: the browser will never fallback via the CSS, but match the first font on the list to an equivalent found on the system via fontconfig's fallback mechanisms. It will be an educated guess and possibly do the right thing but it won't be what the web designer intended.

This basically strengthens your point: free fonts should be first in the list.

Regards, Faidon

[1]: I say "probably", because I vaguely remember the interactions between Firefox & fontconfig to be complicated. Maybe they're being smarter -- someone should test :)

On Sun, Oct 27, 2013 at 11:11 PM, Faidon Liambotis faidon@wikimedia.orgwrote:

On Mon, Oct 28, 2013 at 01:32:30PM +1100, Tim Starling wrote:

...

Yes, we should prefer to use free software. We should also strive to ensure that our support for users on non-free platforms is optimal, as long as that doesn't negatively impact on users of free platforms. So I don't think it is a problem to specify non-free fonts in font lists.

It's a bit more complicated than that. Linux distros ship with fontconfig (which is used by Cairo, which in turn is used by at least Firefox). Fontconfig aliases fonts via a set of rules and the default rules map popular non-free fonts to their free metric equivalents, or generics. e.g. $ fc-match Helvetica n019003l.pfb: "Nimbus Sans L" "Regular" ...

This effectively means that, for Linux, having the free fonts at the end of the CSS font selection is probably[1] a no-op: the browser will never fallback via the CSS, but match the first font on the list to an equivalent found on the system via fontconfig's fallback mechanisms.

Almost. fontconfig will use the first font in the font stack that has a positive match. "Helvetica Neue" doesn't mean anything (so alone it would give "Deja Vu Sans"), but the following "Helvetica" has a alias to "Nimbus Sans L" with binding="same" in /etc/fonts/* , so Firefox uses that.

It will be an educated guess and possibly do the right thing but it won't be what the web designer intended.

For the 2012 Login and Create account form redesign, the web designer (Munaf Assaf and others) intended Helvetica Neue for text and Georgia for some numbers. fc-match lets free software get close to that intended look. The right thing happens! (The Login and Create account forms looked good on my Ubuntu for the time when they specified a font stack.[*]) Free OSes sometimes improve their supplied fonts and matching rules, so it's possible they'll later ship something that matches even better. For example Google's new Roboto is a nice Helvetica Neue. Brave users can make the decision themselves by hacking /etc/fonts/*.

This basically strengthens your point: free fonts should be first in the

list.

Only if the free font looks better.

[1]: I say "probably", because I vaguely remember the interactions between

Firefox & fontconfig to be complicated. Maybe they're being smarter -- someone should test :)

Firefox works this way. It seems my Chromium prefers Nimbus Sans L even for 'sans serif'; it could be my setup, or https://code.google.com/p/chromium/issues/detail?id=242046 I would love to know what Android tablets do.

[*] The local improvement to fonts on those forms made them inconsistent with the rest of MediaWiki, so their font stack was removed. The VectorBeta feature applies better typography everywhere. It's really nice IMO.

-- =S Page Features engineer

On 10/28/2013 07:43 AM, Liangent wrote:

btw. Be aware of internationalization issues: not to say that fonts are usually tied to a (group of) alphabets. Even digits can be affected by the language info of the context they live.

See [1]: this is the standard English Wikipedia signup screen, and [2]: with ?uselang=zh-cn added.

[1] http://imagebin.org/275031 [2] http://imagebin.org/275032

Just for the record, neither of those are Georgia. They have both been substituted/fallbacked. Georgia has very recognizable numbers since they shift on the baseline. See the right column of https://www.mediawiki.org/wiki/File:Account-Creation-Mockup-ByTheNumbers.png

It is indeed interesting that the system uses different fonts based on the language, even for the numerals. The Chinese one isn't even a serif, although 'serif' is the last in the stack.

Matt Flaschen

Thanks for doing this research!

I notice that while Liberation Sans got a high score for appearance, it got a very low technical score... Since it is a FOSS project < https://fedorahosted.org/liberation-fonts/%3E we should attempt to file bug reports with Red Hat about any problems we discover, and/or post our findings on the fedora-fonts mailing list.

-- brion

On Mon, Mar 3, 2014 at 11:57 AM, Ryan Kaldari rkaldari@wikimedia.orgwrote:

I spent most of Friday working on font evaluation with the designers. First I presented them with a blind "taste test" of 10 potential body fonts. 7 of them were FOSS fonts, 3 were commercial. Each one was used to render an identical section of Lorem Ipsum text in a MedaWiki page. Each font was given a "style" score based on readability, neutrality, and "authority" (does the font look like it conveys reliable information). Interestingly, of the 4 fonts that they preferred, 3 of them were the commercial fonts. The only FOSS font that scored highly was Liberation Sans.

Next, I did a blind technical evaluation. For this, I used each of the 10 fonts to render combining diacritics, ties, and other "obscure" Unicode features. Then I gave each font a score based on how many problems it had rendering the characters.

Finally, I researched the installation base of each font, i.e. what operating systems it is installed on by default and also gave scores for this.

The results can be seen at

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval... .

The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and Liberation Sans, so I'm going to suggest that all of these fonts be included in the body stack, with the preference order based on the "style" scores. Although Liberation Sans and Helvetica Neue tied on the style score, I'm going to suggest that Liberation Sans go first since it is a FOSS font:

div#content { font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif; }

Additional feedback is welcome.

Ryan Kaldari

On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org

...

wrote:

...

I came across Gerrit change 79948[1] today, which makes "VectorBeta" use a pile of non-free fonts (with one free font thrown in at the end as a sop). Is this really the direction we want to go, considering that in many other areas we prefer to use free software whenever we can?

Looking around a bit, I see this has been discussed in some "back corners"[2][3] (no offense intended), but not on this list and I don't see any place where free versus non-free was actually discussed rather than being brought up and then seemingly ignored.

In case it helps, I did some searching through mediawiki/core and WMF-deployed extensions for font-family directives containing non-free fonts. The results are at https://www.mediawiki.org/wiki/User:Anomie/font-family (use of non-staff account intentional).

[2]:

https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#A...

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Ryan,

This is useful. Am I assuming accurately that you looked only at Latin language fonts focused on English. Did you consider Google webfonts too.

I would be interested in reusing your test criteria for other language fonts too. Thanks for your efforts so far.

Best Alolita On Mar 3, 2014 11:57 AM, "Ryan Kaldari" rkaldari@wikimedia.org wrote:

I spent most of Friday working on font evaluation with the designers. First I presented them with a blind "taste test" of 10 potential body fonts. 7 of them were FOSS fonts, 3 were commercial. Each one was used to render an identical section of Lorem Ipsum text in a MedaWiki page. Each font was given a "style" score based on readability, neutrality, and "authority" (does the font look like it conveys reliable information). Interestingly, of the 4 fonts that they preferred, 3 of them were the commercial fonts. The only FOSS font that scored highly was Liberation Sans.

Next, I did a blind technical evaluation. For this, I used each of the 10 fonts to render combining diacritics, ties, and other "obscure" Unicode features. Then I gave each font a score based on how many problems it had rendering the characters.

Finally, I researched the installation base of each font, i.e. what operating systems it is installed on by default and also gave scores for this.

The results can be seen at

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval... .

The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and Liberation Sans, so I'm going to suggest that all of these fonts be included in the body stack, with the preference order based on the "style" scores. Although Liberation Sans and Helvetica Neue tied on the style score, I'm going to suggest that Liberation Sans go first since it is a FOSS font:

div#content { font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif; }

Additional feedback is welcome.

Ryan Kaldari

On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org

...

wrote:

...

I came across Gerrit change 79948[1] today, which makes "VectorBeta" use a pile of non-free fonts (with one free font thrown in at the end as a sop). Is this really the direction we want to go, considering that in many other areas we prefer to use free software whenever we can?

Looking around a bit, I see this has been discussed in some "back corners"[2][3] (no offense intended), but not on this list and I don't see any place where free versus non-free was actually discussed rather than being brought up and then seemingly ignored.

In case it helps, I did some searching through mediawiki/core and WMF-deployed extensions for font-family directives containing non-free fonts. The results are at https://www.mediawiki.org/wiki/User:Anomie/font-family (use of non-staff account intentional).

[2]:

https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#A...

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hi everyone,

I wanted to give everyone an update from an in-person conversation I had with Ryan (see...see...I do talk to people in person!) :-) Ryan and crew, I'm really glad you all are following through with documentation and doing all of the testing you are. Thank you!

If we're going to bias toward Liberation Sans based on the install base, we need to make sure we're testing with the version of Liberation Sans which is actually in widespread distribution in the context it'll be used (Linux). I believe that is the 1.07.* for Ubuntu at least, and I think that's true for the other Linux distros as well, due to some still unresolved(?) hinting problems with Liberation Sans 2.00. This is made tougher by the fact that I think Red Hat is distributing a font billed as 1.07 on their website, but I think is in fact 2.00 when you open up the tarball. I'm not positive about this...I spent a lot of time on this a couple weekends ago, and haven't touched it since, so I could be a bit rusty on it and may have been misreading things. It may also be that Liberation Sans 1.07.x has better diacritic support than Liberation Sans 2.00. Based on what Ryan showed me with 2.00, it's got a number of technical issues.

In lieu of finding a reliable source to download Liberation Sans 1.07.x, I sent Ryan a copy of 1.07.3 from my machine, which I believe he's in the process of working with now.

Rob

On Mon, Mar 3, 2014 at 12:58 PM, Ryan Kaldari rkaldari@wikimedia.orgwrote:

Yes, we only looked at Latin fonts. We are working on an FAQ, however, that explains how wikis that use non-Latin scripts can specify their own font stack using MediaWiki:Vector.css.

Ryan Kaldari

On Mon, Mar 3, 2014 at 12:26 PM, Alolita Sharma <asharma@wikimedia.org

...

wrote:

...

Ryan,

This is useful. Am I assuming accurately that you looked only at Latin language fonts focused on English. Did you consider Google webfonts too.

I would be interested in reusing your test criteria for other language fonts too. Thanks for your efforts so far.

Best Alolita On Mar 3, 2014 11:57 AM, "Ryan Kaldari" rkaldari@wikimedia.org wrote:

...

I spent most of Friday working on font evaluation with the designers.

First

...

I presented them with a blind "taste test" of 10 potential body fonts.

7

...

of

...

them were FOSS fonts, 3 were commercial. Each one was used to render an identical section of Lorem Ipsum text in a MedaWiki page. Each font was given a "style" score based on readability, neutrality, and "authority" (does the font look like it conveys reliable information).

Interestingly,

...

...

of the 4 fonts that they preferred, 3 of them were the commercial

fonts.

...

...

The only FOSS font that scored highly was Liberation Sans.

Next, I did a blind technical evaluation. For this, I used each of the

10

...

...

fonts to render combining diacritics, ties, and other "obscure" Unicode features. Then I gave each font a score based on how many problems it

had

...

...

rendering the characters.

Finally, I researched the installation base of each font, i.e. what operating systems it is installed on by default and also gave scores

for

...

...

this.

The results can be seen at

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_eval...

...

...

.

The highest scoring fonts were: Arial, Helvetica, Helvetica Neue, and Liberation Sans, so I'm going to suggest that all of these fonts be included in the body stack, with the preference order based on the

"style"

...

scores. Although Liberation Sans and Helvetica Neue tied on the style score, I'm going to suggest that Liberation Sans go first since it is a FOSS font:

div#content { font-family: Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif; }

Additional feedback is welcome.

Ryan Kaldari

On Sat, Oct 26, 2013 at 9:43 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org

...

wrote:

...

I came across Gerrit change 79948[1] today, which makes "VectorBeta" use a pile of non-free fonts (with one free font thrown in at the end as a sop). Is this really the direction we want to go, considering that in many other areas we prefer to use free software whenever we can?

Looking around a bit, I see this has been discussed in some "back corners"[2][3] (no offense intended), but not on this list and I

don't

...

...

...

see any place where free versus non-free was actually discussed

rather

...

...

...

than being brought up and then seemingly ignored.

In case it helps, I did some searching through mediawiki/core and WMF-deployed extensions for font-family directives containing

non-free

...

...

...

fonts. The results are at https://www.mediawiki.org/wiki/User:Anomie/font-family (use of non-staff account intentional).

[2]:

https://www.mediawiki.org/wiki/Talk:Wikimedia_Foundation_Design/Typography#A...

...

...

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Mon, Mar 3, 2014 at 2:19 PM, Brian Wolff bawolff@gmail.com wrote:

On Mar 3, 2014 4:58 PM, "Ryan Kaldari" rkaldari@wikimedia.org wrote:

...

Yes, we only looked at Latin fonts. We are working on an FAQ, however,

that

...

explains how wikis that use non-Latin scripts can specify their own font stack using MediaWiki:Vector.css.

Ryan Kaldari

I dont think users should be responsible for that sort of thing. Could we do per-language css and only do this on en/other known good languages if we know that its going to be a bad choice for some languages?

There are only a couple of languages in which we know this stack will be a "bad choice" (so far, Navajo and Vietnamese). In most languages that use non-Latin scripts, the font-family declaration will have little or no effect, but the readability will be improved by increasing the leading and font-size. Specifically the existing small leading is often a problem for Indic scripts and the existing small font-size is often a problem for logographic scripts.

Ryan Kaldari

Hoi, Given that you only researched Latin fonts, did you consider the coverage of these fonts for languages? Not all fonts are created equal, they often do not necessarily cover all the characters that are needed for specific languages.

Consequently, you cannot apply your work to other languages without considering this as well. Thanks, GerardM

On 3 March 2014 23:33, Ryan Kaldari rkaldari@wikimedia.org wrote:

On Mon, Mar 3, 2014 at 2:19 PM, Brian Wolff bawolff@gmail.com wrote:

...

On Mar 3, 2014 4:58 PM, "Ryan Kaldari" rkaldari@wikimedia.org wrote:

...

Yes, we only looked at Latin fonts. We are working on an FAQ, however,

that

...

explains how wikis that use non-Latin scripts can specify their own

font

...

...

stack using MediaWiki:Vector.css.

Ryan Kaldari

I dont think users should be responsible for that sort of thing. Could we do per-language css and only do this on en/other known good languages if

we

...

know that its going to be a bad choice for some languages?

There are only a couple of languages in which we know this stack will be a "bad choice" (so far, Navajo and Vietnamese). In most languages that use non-Latin scripts, the font-family declaration will have little or no effect, but the readability will be improved by increasing the leading and font-size. Specifically the existing small leading is often a problem for Indic scripts and the existing small font-size is often a problem for logographic scripts.

Ryan Kaldari _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Am 03.03.2014 21:38, schrieb Sumana Harihareswara:

Ryan, thank you superlatively for doing and documenting this research.

+1

-- daniel

On Mon, Mar 3, 2014 at 2:57 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:

I spent most of Friday working on font evaluation with the designers.

[...]

given a "style" score based on readability, neutrality, and "authority" (does the font look like it conveys reliable information).

What does "neutrality" mean in the context of a font?

I'm having trouble figuring out what "authority" might actually mean besides "Does this seem familiar to me from sites I use for reference?".

Did they actually rate these separately, or was it just one number covering all three?

Something this subjective could probably do with a much more diverse sample.

Next, I did a blind technical evaluation. For this, I used each of the 10

fonts to render combining diacritics, ties, and other "obscure" Unicode features. Then I gave each font a score based on how many problems it had rendering the characters.

It seems to me that the technical evaluation doesn't need to be blind, you just look at "is the diacritic/tie/etc correctly positioned?".

Are there any details on this technical evaluation? What exactly was tested, and in what ways did the fonts fail? Ideal IMO would be a table of images (or a big image laid out as a table).

Were the technical results consistent across backends?

On Mon, Mar 3, 2014 at 6:14 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:

One number covering all three.

One thing I wonder about is the difference in style score for Arimo (5) and Liberation Sans (10). Apparently the only difference between the two is the hinting.

Something this subjective could probably do with a much more diverse sample.

...

Do you mean a more diverse sample of fonts, a more diverse sample of text, or a more diverse sample of evaluators?

Evaluators.

You can see a sample from the technical tests in the file attached to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1072095

Sorry I don't have more documentation for that.

Interesting.

In some local testing, it seems that Liberation Sans (1.07.3) isn't actually being used for any of the diacritics on [[en:User:Kaldari/Font_test]]. If I change the font-family to "'Liberation Sans', 'Unicode BMP Fallback SIL', 'sans-serif'" and preview I get fallback characters on top of all the 'g's.

OTOH, Liberation Sans with DejaVu Sans as a fallback (default sans-serif on my system) does better than your screenshot. Oddly, using Arimo as a fallback doesn't work very well.

I haven't tested on different backends yet, but that's what part of what I was talking with Rob about today. Apparently the font hinting can cause significantly different rendering quality on different operating systems. Any help assessing this would be appreciated.

If you tell me what exactly you want screenshots of, I can make screenshots for all the fonts on your list except Helvetica and Helvetica Neue with Debian's font renderer, in Firefox (really Iceweasel) and Chromium.

On Mon, Mar 3, 2014 at 1:22 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.orgwrote:

What does "neutrality" mean in the context of a font?

I'm having trouble figuring out what "authority" might actually mean besides "Does this seem familiar to me from sites I use for reference?".

These are not terms with a purely objective measurement Brad, even if they have a dictionary definition. It's a qualitative, subjective assessment. As a secondary part of the design goals (behind readability) is to convey these subjective qualities, you have to use a subjective measurement system.

Something this subjective could probably do with a much more diverse sample.

Agreed, it would be awesome if we could make a little Surveymonkey to let anyone do this blind test. Though I wouldn't necessarily trust Wikitech readers not to use browser devtools to cheat. ;-)

A fun example of how similar qualities can be measured is the following experiment in trustworthiness of fonts: http://opinionator.blogs.nytimes.com/2012/08/08/hear-all-ye-people-hearken-o...

I actually consulted our research and data team (Dario Taraborelli and Aaron Halfaker) about whether we should A/B test the beta with readers. Their reply was that a split test was not likely to produce statistically significant results in reader-related metrics like time on site, pageviews per unique visitor, etc. and that we have a great deal of trouble measuring these things with precision anyway. Producing a muddled and potentially flawed A/B test is much much worse than producing a small qualitative assessment that we know to take with a large grain of salt. :-)

Ryan, *thank you* very much for the research, and for contacting the Liberation Sans maintainers with specific bugs.

On 03/05/2014 02:00 PM, Ryan Kaldari wrote:

What do people think of the following stack:

Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif;

After so much discussion, it would be useful to have a table showing which fonts are rendered by the most popular browsers in the most popular platforms [1] when you specify

a) sans-serif;

b) Arimo, Liberation Sans, sans-serif;

c) Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif;

This way we can see what happens exactly when you define fonts or not, when you define only free fonts or also proprietary. We will also be able to see where exactly this picture differs from the vision of the promoters of proprietary fonts.

I think this table is going to be useful to defend the decision, regardless of which decision is made.

Based on the results we might conclude that e.g. there is no need to specify Helvetica / Arial because they are already picked by the browsers that would display them when explicitly specified.

We might also find out where does Helvetica Neue appear or not based on each option, and this would open the possibility to file bugs or provide feedback to the specific projects.

Imagine if all this discussion could be solved by proposing a patch to the Webkit project, just defining Helvetica Neue as a fallback for Arimo and Liberation Sans.

[1] Proposed browsers:

Chrome (Windows, Mac) Firefox (Windows, Mac) MSIE Safari Android iPhone iPad

http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm

On 03/06/2014 12:21 PM, Quim Gil wrote:

On 03/05/2014 02:00 PM, Ryan Kaldari wrote:

...

What do people think of the following stack:

Arimo, Liberation Sans, Helvetica Neue, Helvetica, Arial, sans-serif;

it would be useful to have a table showing which fonts are rendered by the most popular browsers in the most popular platforms [1] when you specify

Please help filling this table:

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test

BUT BEFORE please check the wikitext code to assure that the syntax is correct, and therefore the tests will be valid. Thank you!

PS: I don't have any of the "most popular browsers in the most popular platforms". I have started a second table of Linux desktop combinations, just for the fun of it.

Thank you for the people that has already filled data and improved the page!

https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test

On 03/07/2014 12:39 AM, Martijn Hoekstra wrote:

In the "mobile browsers" I'm missing chrome for Android. Is that getting reported with something else? Maybe as "android"? It's hard to believe chrome for android is less popular than all the others on the list.

If you are missing a combination, just add it (as others have done).

We have already interesting data, although most likely distorted in some cases by the free fonts installed by the users in Windows, either directly or perhaps indirectly (I suspect that OpenOffice & LibreOffice in Windows might carry Liberation Sans with them, and this is why it is available for some browsers there).