There have recently been questions whether WMF is able to serve webfonts. Some people think that because of the issues that led to disabling webfonts by default in Universal Language Selector (ULS), WMF is not ready to consider webfonts for typography.
I don't think that way. ULS is not a good comparison point because of the following.
1) Universal Language selector is trying to solve a much harder issue than what webfonts are usually used for. It is trying to avoid tofu (missing fonts) which brings a whole list of issues which are not present or are much smaller otherwise: * large fonts for complex scripts, * detecting which fonts are missing, * many fonts per page, * the systems with greatest need of fonts often have bad renderers.
2) WMF has a lot of experience working with web fonts by now. We know how to handle different formats, how to optimally compress fonts and how to check the results in different systems and browsers. In some areas we are even ahead of Google, like non-latin fonts.
Thus, I think that delivering a relative small fonts for simple scripts like latin and cyrillic is something that is possible *if* we are willing to accept that it will take some bandwidth and that page load experience can be affected* if the font is not cached or present locally.
-Niklas
* The unwanted effects of using webfonts are getting smaller and smaller with modern browsers.
Niklas Laxström wrote:
[...]
Thus, I think that delivering a relative small fonts for simple scripts like latin and cyrillic is something that is possible *if* we are willing to accept that it will take some bandwidth and that page load experience can be affected* if the font is not cached or present locally.
- The unwanted effects of using webfonts are getting smaller and
smaller with modern browsers.
I think you're mostly right, though the exact terms of the trade-offs aren't clear here (e.g., "some bandwidth"). We'll need more explicit measurements in order to reach full agreement on what user benefit vs. site performance trade-offs Wikimedia is willing to accept.
It's also necessary to hear from the Wikimedia operations team. In addition to end-users weighing the importance of a feature against its cost, the operations team must also make practical considerations. Some Wikimedia wikis get some substantial traffic. ;-)
MZMcBride
On Thu, Mar 13, 2014 at 07:20:27PM -0400, MZMcBride wrote:
I think you're mostly right, though the exact terms of the trade-offs aren't clear here (e.g., "some bandwidth"). We'll need more explicit measurements in order to reach full agreement on what user benefit vs. site performance trade-offs Wikimedia is willing to accept.
It's also necessary to hear from the Wikimedia operations team. In addition to end-users weighing the importance of a feature against its cost, the operations team must also make practical considerations. Some Wikimedia wikis get some substantial traffic. ;-)
As you say, we need to have more data before we can promise anything, "some bandwidth" isn't enough.
As a general comment though, delivering a small amount of files such as webfonts is a trivial task and we can easily scale the infrastructure to handle *a lot* of additional traffic. It costs, though, both in bandwidth (a dollar amount per mbps) and in upgrades that might be necessary in network ports or hardware upgrades (loadbalancers, routers, servers).
I think at this point it's more useful to focus the discussion on the usefulness of webfonts, especially in combination with the performance impact that they have on clients (a problem that we can't throw money at). If the outcome is that the feature enhances the overall user experience, we'll handle the infrastructure part.
Regards, Faidon
On Thursday 13 March 2014 08:38 PM, Niklas Laxström wrote:
There have recently been questions whether WMF is able to serve webfonts. Some people think that because of the issues that led to disabling webfonts by default in Universal Language Selector (ULS), WMF is not ready to consider webfonts for typography.
I don't think that way. ULS is not a good comparison point because of the following.
- Universal Language selector is trying to solve a much harder issue
than what webfonts are usually used for. It is trying to avoid tofu (missing fonts) which brings a whole list of issues which are not present or are much smaller otherwise:
- large fonts for complex scripts,
- detecting which fonts are missing,
- many fonts per page,
- the systems with greatest need of fonts often have bad renderers.
- WMF has a lot of experience working with web fonts by now. We know
how to handle different formats, how to optimally compress fonts and how to check the results in different systems and browsers. In some areas we are even ahead of Google, like non-latin fonts.
I wonder why people want to serve webfonts by default, eventhough most Wikipedia users don't need it. Webfonts is a nice option, and it must be an option so as if any user or language need it, they can choose it. Overruling a user's / community's settings without asking their opinion is against any freedom WMF represents.
There are various other 'real' issues which are affecting, contribution and rendering of Wikimedia wikis in non-latin languages.
Thus, I think that delivering a relative small fonts for simple scripts like latin and cyrillic is something that is possible *if* we are willing to accept that it will take some bandwidth and that page load experience can be affected* if the font is not cached or present locally.
-Niklas
- The unwanted effects of using webfonts are getting smaller and
smaller with modern browsers.
And requirement of webfonts is also getting smaller and smaller with modern OSs. Even today's mobile OSs have better language support than that of old desktop OSs.
Praveen
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hoi, You do not understand what the existing implementation of Webfonts is about. It is about "not serving tofu". You know, those pesky boxes that represent a character. When tofu is served, no characters can be seen and consequently no information can be read.
Please ask any community if this is what they want. Thanks, GerardM
On 14 March 2014 14:36, praveenp me.praveen@gmail.com wrote:
On Thursday 13 March 2014 08:38 PM, Niklas Laxström wrote:
There have recently been questions whether WMF is able to serve webfonts. Some people think that because of the issues that led to disabling webfonts by default in Universal Language Selector (ULS), WMF is not ready to consider webfonts for typography.
I don't think that way. ULS is not a good comparison point because of the following.
- Universal Language selector is trying to solve a much harder issue
than what webfonts are usually used for. It is trying to avoid tofu (missing fonts) which brings a whole list of issues which are not present or are much smaller otherwise:
- large fonts for complex scripts,
- detecting which fonts are missing,
- many fonts per page,
- the systems with greatest need of fonts often have bad renderers.
- WMF has a lot of experience working with web fonts by now. We know
how to handle different formats, how to optimally compress fonts and how to check the results in different systems and browsers. In some areas we are even ahead of Google, like non-latin fonts.
I wonder why people want to serve webfonts by default, eventhough most Wikipedia users don't need it. Webfonts is a nice option, and it must be an option so as if any user or language need it, they can choose it. Overruling a user's / community's settings without asking their opinion is against any freedom WMF represents.
There are various other 'real' issues which are affecting, contribution and rendering of Wikimedia wikis in non-latin languages.
Thus, I think that delivering a relative small fonts for simple
scripts like latin and cyrillic is something that is possible *if* we are willing to accept that it will take some bandwidth and that page load experience can be affected* if the font is not cached or present locally.
-Niklas
- The unwanted effects of using webfonts are getting smaller and
smaller with modern browsers.
And requirement of webfonts is also getting smaller and smaller with modern OSs. Even today's mobile OSs have better language support than that of old desktop OSs.
Praveen
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 Fri, Mar 14, 2014 at 7:06 PM, praveenp me.praveen@gmail.com wrote:
.. And requirement of webfonts is also getting smaller and smaller with modern OSs. Even today's mobile OSs have better language support than that of old desktop OSs.
For example: My Nexus 5 with modern OS, Android Kitkat has no font for my native language by default.
It's really in the tradeoffs, as others have mentioned.
It is obvious that we would love to get rid of tofu at all time. But what is the effect on readership? As far as I know, a higher delivery speed of a Website increases readership and the other way around. So if there was any way to estimate what the trade-off would be -- i.e. how many readers gained or lost for how much tofu avoided -- that would be great.
Bonus points if we could qualify both sides (e.g. readers who turn into editors vs the other readers, tofu that prevents you from understanding the article vs tofu in a language link you don't care anyway).
I don't think that actual bandwidth costs and loading time are interesting per se for us, but only as secondary indicators.
That's speaking from a fantasy dream world where such metrics are easily accessible :)
On Fri Mar 14 2014 at 8:08:12 AM, Kartik Mistry kartik.mistry@gmail.com wrote:
On Fri, Mar 14, 2014 at 7:06 PM, praveenp me.praveen@gmail.com wrote:
.. And requirement of webfonts is also getting smaller and smaller with
modern
OSs. Even today's mobile OSs have better language support than that of
old
desktop OSs.
For example: My Nexus 5 with modern OS, Android Kitkat has no font for my native language by default.
-- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Friday 14 March 2014 07:54 PM, Gerard Meijssen wrote:
Hoi, You do not understand what the existing implementation of Webfonts is about. It is about "not serving tofu". You know, those pesky boxes that represent a character. When tofu is served, no characters can be seen and consequently no information can be read.
Please ask any community if this is what they want. Thanks, GerardM
Why would every Malayalam Wikimedians suffer webfonts because some language in some other continent has no proper support in OSs. We will not read that language anyhow :-). IMHO, serving webfonts by default only for that language after consulting that community, may be the solution.
On Friday 14 March 2014 08:37 PM, Kartik Mistry wrote:
On Fri, Mar 14, 2014 at 7:06 PM, praveenp me.praveen@gmail.com wrote:
.. And requirement of webfonts is also getting smaller and smaller with modern OSs. Even today's mobile OSs have better language support than that of old desktop OSs.
For example: My Nexus 5 with modern OS, Android Kitkat has no font for my native language by default.
Sorry to hear that. Even my humble Samsung Galaxy Trend (Android 4.1) has pretty good support for atleast Malayalam, Hindi and Tamil. If I remember correctly there was two different fonts and an input method for Malayalam available in the stock phone.
We had to wait untill service pack 2 for a decent Malayalam font while Windows XP released.
Praveen
I just want to clarify that I was highlighting the possibility of considering webfonts for *typography*.
I expect everyone to know by now that tofu issue is not yet solved and people are working on it.
-Niklas
On Thu, Mar 13, 2014 at 8:08 AM, Niklas Laxström niklas.laxstrom@gmail.comwrote:
There have recently been questions whether WMF is able to serve webfonts. Some people think that because of the issues that led to disabling webfonts by default in Universal Language Selector (ULS), WMF is not ready to consider webfonts for typography.
I don't think that way
Me neither; I agree with much of what you are saying.
I'm not sure why Odder abandoned https://gerrit.wikimedia.org/r/#/c/115153/ (Odder, I'm sorry if my comments were hurtful for some reason -- and I want to say that I appreciate the fact that you use your technical savvy to help communities make their voices heard in technical forums.) What I was actually going to propose is that the font required by Hebrew Wikisource be loaded unconditionally, for all pages, by being referenced in Common.css. It needs some scrutiny first, but in principle it strikes me as the right way to go.
I also think we should consider biting the performance bullet and including a font like Noto https://code.google.com/p/noto/ on all wikis. Again, not a decision to undertake lightly, but something we should definitely consider. It won't solve the problem of individual wikis needing a font for the content language that is suitable for inputing and editing content, but it may be good enough to cover the cases of occasional content in non-primary scripts on most wikis. I filed < https://bugzilla.wikimedia.org/show_bug.cgi?id=59983%3E about that, though to my regret I did so at the height of the ULS drama so my tone was probably not very inviting to future conversation. But if you can stand to ignore it and to think the issue through, please do comment.
And finally: I also absolutely agree with Niklas that there remains a large problem that would not be addressed by either approach, and that a platform like ULS, backed by sufficient data and some trial-and-error experience, represents a good approach for solving that.
There is one other thing that I think we should be doing: we should strive to offer the very best HOWTO on the internet for obtaining and installing additional fonts for users, so that we empower to use the internet in their language, not just on Wikimedia (and MediaWiki) wikis, but across the web. If something like that already exists and I am simply an ignorant oaf (which is quite possible) than I eat my hat by way of apology :)
wikitech-l@lists.wikimedia.org