subject:"Re\: \[Wikitech\-l\] Free fonts and Windows users"

On Thu, Apr 10, 2014 at 4:26 PM, Brian Wolff bawo...@gmail.com wrote:

I would add as an issue, that there are major variance in the font
selection based on platform and configuration. For some platforms, the
typo refresh chooses a font that is significantly lower quality than
the browser default (The opposite of bad defaults concern. I think
the browser choosing a bad default is much rarer then typo refresh
overriding the good browser default with something bad). So the
question becomes, to what extent are we willing to degrade some users
experience in order to make other user's experiance better. Which
immediately raises the question of what is the level of degradation,
and for how many people, compared to what is the level of user
experience improvement, and for what percentage is the experience
improved.

By lower quality I mean both subjectively, but also objectively. For
example, today I was reading

https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1%27s_900th_Grand_Prix
(enwikinews is one of the few wikis I haven't overridden the font
changes with css). At first I thought there was a typo in the image
caption toward the end of the page, an extra space between prote and
stor. But no, the kerning on the font chosen is just literally that
bad, that you can't tell if it is an extra space, or just a kerning
error. I call that objectively bad (There's other things I don't like
about the font choice, but they are more touchy-feely subjective)

I've filed this at https://bugzilla.wikimedia.org/show_bug.cgi?id=63807 so
we can talk in more detail outside the thread. I tested again in Chrome and
Firefox on Linux.

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

Re: [Wikitech-l] Free fonts and Windows users; final plea!


On 11-04-2014 04:35, Steven Walling wrote:


How are these specific, replicable bugs? DJ is saying things the current
solution is not working and we cannot do better but there is no
evidence about why this is the case for such a large number of users that
it requires a revert back to plain sans-serif.



People are talking in generalities and about problems related to areas like
non-Latin script support, but not referring to bugs filed and which would
be fixed by the suggested patch. Brian's recent comment here is an example
of what we are asking to hear, though I don't think that requires a full
revert.


[1] shows half the world complaining about the typography refresh.

I'm sorry, but this is beginning to be like VE all over again; all I see 
now coming out of the foundation is a big, unpenetrable progaganda 
machine with a broken record: There is no problem! This is a good 
change! There are no bugs!


Steven, it has been sufficiently demonstrated that the single, global 
font stack is technically flawed and must be reverted. With all due 
respect to the design team, they are *not* engineers and may not be 
aware of the problems as they have emerged.


I will explain one more time: free/non-free fonts are not the issue, 
MediaWiki is now forcing a Latin font stack that does not work in 
non-Latin installations. This does not only affect current Mediawiki 
wikis but will also affect new non-Latin MW 1.23 installations; they all 
had/have to fix this one way or another, usually by resetting the font 
stack.


We must focus on a system that delivers a font stack on a per-language 
basis. But that cannot happen as long as the global font stack is in place.



Unless you can raise issues that cause actual functional problems that
outweigh the benefits of the new body font stack, I don't think merging
that patch is required to improve things and is worth the churn in user
experience for millions of readers.


*ANY* functional problem outweighs the purported benefits. That is 
because actual functional problems should never be weighed; they should 
be fixed on sight.


Please Steven, and the foundation in general, PLEASE step of the 
propaganda wagon and do the responsible thing; remove the font stacks so 
that we can focus on a *real* solution that actually *does* benefit the 
entire world.


I am really, really affraid that refusing to +2 this patch is going to 
affect future attempts to fix this on a per-language basis.


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users; final plea!

2014-04-11 Thread Jon Robson

I keep hearing about ALLL THE BUGS but I've not seen anything on
Bugzilla. This leads me to believe I've not been cc'ed on them or they
haven't been raised (which would be bad). Please can someone raise
these on Bugzilla - if these are being raised on wikis they are not
getting in front of people. If their are still bugs these are being
lost in the noise of this discussion. Maybe if we can clearly see
where the bugs are this can resolved much quicker. It's hard to argue
about the font stack if there are 20 bugs showing

* a screenshot of poor rendering
* the language
* the operating system
* the browser being used.
* plus points if we can identify via inspector the font family being used

Please feel free to raise these and cc me on them.

I've been working on this in my spare time, and I'm hoping to get some
spare time sometime next week to clean this up.

Regardless of the outcome, it would be extremely useful to document
these issues for The Web.

On Fri, Apr 11, 2014 at 4:11 AM, Erwin Dokter er...@darcoury.nl wrote:
 On 11-04-2014 04:35, Steven Walling wrote:


 How are these specific, replicable bugs? DJ is saying things the current
 solution is not working and we cannot do better but there is no
 evidence about why this is the case for such a large number of users that
 it requires a revert back to plain sans-serif.



 People are talking in generalities and about problems related to areas
 like
 non-Latin script support, but not referring to bugs filed and which would
 be fixed by the suggested patch. Brian's recent comment here is an example
 of what we are asking to hear, though I don't think that requires a full
 revert.


 [1] shows half the world complaining about the typography refresh.

 I'm sorry, but this is beginning to be like VE all over again; all I see now
 coming out of the foundation is a big, unpenetrable progaganda machine with
 a broken record: There is no problem! This is a good change! There are no
 bugs!

 Steven, it has been sufficiently demonstrated that the single, global font
 stack is technically flawed and must be reverted. With all due respect to
 the design team, they are *not* engineers and may not be aware of the
 problems as they have emerged.

 I will explain one more time: free/non-free fonts are not the issue,
 MediaWiki is now forcing a Latin font stack that does not work in non-Latin
 installations. This does not only affect current Mediawiki wikis but will
 also affect new non-Latin MW 1.23 installations; they all had/have to fix
 this one way or another, usually by resetting the font stack.

 We must focus on a system that delivers a font stack on a per-language
 basis. But that cannot happen as long as the global font stack is in place.

 Unless you can raise issues that cause actual functional problems that
 outweigh the benefits of the new body font stack, I don't think merging
 that patch is required to improve things and is worth the churn in user
 experience for millions of readers.


 *ANY* functional problem outweighs the purported benefits. That is because
 actual functional problems should never be weighed; they should be fixed on
 sight.

 Please Steven, and the foundation in general, PLEASE step of the propaganda
 wagon and do the responsible thing; remove the font stacks so that we can
 focus on a *real* solution that actually *does* benefit the entire world.

 I am really, really affraid that refusing to +2 this patch is going to
 affect future attempts to fix this on a per-language basis.

 Regards,
 --
 Erwin Dokter


 ___
 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

Re: [Wikitech-l] Free fonts and Windows users; final plea!


On 11-04-2014 13:11, Erwin Dokter wrote:


[1] shows half the world complaining about the typography refresh.


I forgot to include the URL:

[1] 
https://www.mediawiki.org/wiki/Talk:Typography_refresh#Languages_problems


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users; final plea!


On 11-04-2014 18:42, Jon Robson wrote:

I keep hearing about ALLL THE BUGS but I've not seen anything on
Bugzilla.


That's because you don't *want* to see... Most of the reports on [1] are 
from readers who don't know anything about Bugzilla. That doesn't make 
that anything less valid.


Since that page was linked as the primary feedback page when the refresh 
was announced, it should be the first place to check for error reports. 
Claiming non-existence of Bugzilla reports is just plain selective 
ignorance.


There is also a tracking bug [2] with plenty bugs attached, among the 
[3], [4] and [5]; *all* language related. Buth the bug reports and 
Typography talk page have plenty of screenshots.


[1] 
https://www.mediawiki.org/wiki/Talk:Typography_refresh#Languages_problems

[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=63549
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=63720
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=63718
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=63817

Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users; final plea!

On Fri, Apr 11, 2014 at 9:44 AM, Erwin Dokter er...@darcoury.nl wrote:

 I forgot to include the URL:

 [1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#
 Languages_problems


Out of all of these, the most clear is that serifs are not great for the
headings in CJK (Chinese, Japanese, Korean) languages. This seems to be
true even of default 'serif', per
https://bugzilla.wikimedia.org/show_bug.cgi?id=63817

In the interim, I'm going to help the wikis with these languages if they
want to set a local override. Starting next week, I think Jon and I would
like to explore how to extend our Less variables to set a better default
for headings in CJK languages. (I will file a bug today).

This is a pretty important enhancement for the long run I think. There are
wikis like Farsi and Japanse Wikipedia that have needed to override the
default settings basically forever, to get good basic readability. If we
can use Less to set language-specific fonts then we can start upstreaming
some of the settings that have lingered in Vector and Common CSS for a long
time.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

On Fri, Apr 11, 2014 at 10:01 AM, Erwin Dokter er...@darcoury.nl wrote:

 There is also a tracking bug [2] with plenty bugs attached, among the [3],
 [4] and [5]; *all* language related. Buth the bug reports and Typography
 talk page have plenty of screenshots.

 [1] https://www.mediawiki.org/wiki/Talk:Typography_refresh#
 Languages_problems
 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=63549
 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=63720
 [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=63718
 [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=63817


3 is not language-related, it's about how some users have bad (basically
knockoff) versions of Helvetica installed by HP printers or the user, which
render poorly on older Windows systems. We're trying to figure out whether
this is a real problem at scale, or whether the best thing to recommend is
to simply turn off those fonts, since they won't render well on any site.

4 is a bug that needs to be dealt with in ULS, per Santhosh's comment at
https://bugzilla.wikimedia.org/show_bug.cgi?id=63718#c5

5 will be fixed per what I said in the email just before.

The one thing on the mediawiki.org Talk page we haven't fully investigated
is the potential issue with inconsistent x-height in Cyrillic. We still
need to figure out whether that's font specific, browser specific or what.
There are no details present about what OS/font is used in that report, so
we need to investigate how widely applicable the report actually is.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

2014-04-11 Thread Brian Cox

 Since that page was linked as the primary feedback page when the refresh
was
 announced, it should be the first place to check for error reports.
Claiming
 non-existence of Bugzilla reports is just plain selective ignorance.

I disagree. Bugzilla is where we report bugs. If no one raises bugs as
they will go lost.

Perhaps all the user reported bugs should be added to Bugzilla for tracking
purposes. But it's not reasonable to expect the average user to report them
there.

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

Re: [Wikitech-l] Free fonts and Windows users; final plea!

On Fri, Apr 11, 2014 at 11:17 AM, Brian Cox
nativeforeignerw...@gmail.comwrote:

 Perhaps all the user reported bugs should be added to Bugzilla for tracking
 purposes. But it's not reasonable to expect the average user to report them
 there.

 Brian/NF


Yes I think we definitely need to track things in Bugzilla, but you're
right Brian. The average reader especially is not going to be able to
figure out bug filing.

Nemo, Jared, and others have been trying to migrate bugs there or ask
people to do so where they can.  Nemo in particular deserves thanks for
trying to spend some time helping us wrangle Bugzilla for typography
refresh. :) Once things are tracked there and we can replicate them, we'll
do our best to fix issues that are widely applicable.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-11 Thread Bartosz Dziewoński


I have merged the Gerrit change (https://gerrit.wikimedia.org/r/#/c/124475/),
restoring the body font to sans-serif. The heading font is unchanged for now.

I've read the entire wikitech-l thread (89 emails as of writing) and
pondered this carefully. My summary of the situation is:

* This font stack, according to WMF Design, only provides real
  improvements for Macs (~6% of Wikimedia sites visitors per
  http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm)
  and should be (nearly) identical to defaults for other systems.
  However, it causes major rendering issues for an unspecified number
  of Windows and Linux users (especially with, respectively, Helvetica
  and Nimbus Sans L; see both open and closed dependencies of bug
  63549).
* This font stack also apparently causes issues with non-Latin-script
  languages (not very well-specified ones, though; more bug reports
  like bug 63817 would be welcome); it's serious enough for at least
  one affected Wikimedia wiki (the Japanese Wikipedia) to have already
  reset the stack to sans-serif. This might affect the serif heading
  fonts more than the sans-serif body fonts (again, more precise
  reports needed).
* The wikitech-l discussion, as well as various on-wiki discussions
  (e.g. on WP:VPT on the English Wikipedia) have been overwhelmingly
  in favor of restoring the plain sans-serif font definition.
* Orthogonally to these issues, all other aspects of the typography
  refresh have been generally considered successful and minor problems
  with them have been quickly fixed.

Based on the points above and my own common sense I think this should
be merged, and a similar follow-up for serif heading fonts might also
be necessary (but that's obviously a lower-severity problem, there
isn't that much text in headings). Steven, I'm sorry, but I'm
overriding your -2.

(I'm posting this on the Gerrit change
https://gerrit.wikimedia.org/r/#/c/124475/, on the tracking bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 and in the
wikitech-l thread. Please reply on wikitech-l.)

--
Matma Rex

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

Re: [Wikitech-l] Free fonts and Windows users; final plea!

2014-04-11 Thread Andre Klapper

On Fri, 2014-04-11 at 09:42 -0700, Jon Robson wrote:
 I keep hearing about ALLL THE BUGS but I've not seen anything on
 Bugzilla.

https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 dependency list
plus likely stuff on
https://www.mediawiki.org/wiki/Talk:Typography_refresh that I'd expect
the developers to read and convert into bug reports, when necessary.

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


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

Re: [Wikitech-l] Free fonts and Windows users; final plea!


On 11-04-2014 20:00, Jon Robson wrote:


Please don't accuse me of things that are not true. I do want to see
these things, but I have to manage 1) mailing lists 2) bugzilla 3)
wiki pages (which i have to know exist). I am only human. Thanks for
the links to bugs I've cc'ed myself on all of these.


That was not my intention, I'm sorry. But I am getting so frustrated 
because the foundation keeps giving the impression that it does not even 
acknowledge that there is a problem, or at least refuses to remedy it by 
clinging on the currently broken implementaion.



Since that page was linked as the primary feedback page when the refresh was
announced, it should be the first place to check for error reports. Claiming
non-existence of Bugzilla reports is just plain selective ignorance.


I disagree. Bugzilla is where we report bugs. If no one raises bugs as
they will go lost.


Then that should have been in the FAQ. The announcement only sends the 
readers to the talk page to give feedback.


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

On Fri, Apr 11, 2014 at 11:42 AM, Bartosz Dziewoński matma@gmail.comwrote:

I have merged the Gerrit change (https://gerrit.wikimedia.org/
r/#/c/124475/),
restoring the body font to sans-serif. The heading font is unchanged for
now.

I've read the entire wikitech-l thread (89 emails as of writing) and
pondered this carefully. My summary of the situation is:

* This font stack, according to WMF Design, only provides real
improvements for Macs (~6% of Wikimedia sites visitors per
http://stats.wikimedia.org/wikimedia/squids/
SquidReportOperatingSystems.htm)
and should be (nearly) identical to defaults for other systems.
However, it causes major rendering issues for an unspecified number
of Windows and Linux users (especially with, respectively, Helvetica
and Nimbus Sans L; see both open and closed dependencies of bug
63549).
* This font stack also apparently causes issues with non-Latin-script
languages (not very well-specified ones, though; more bug reports
like bug 63817 would be welcome); it's serious enough for at least
one affected Wikimedia wiki (the Japanese Wikipedia) to have already
reset the stack to sans-serif. This might affect the serif heading
fonts more than the sans-serif body fonts (again, more precise
reports needed).
* The wikitech-l discussion, as well as various on-wiki discussions
(e.g. on WP:VPT on the English Wikipedia) have been overwhelmingly
in favor of restoring the plain sans-serif font definition.
* Orthogonally to these issues, all other aspects of the typography
refresh have been generally considered successful and minor problems
with them have been quickly fixed.

Based on the points above and my own common sense I think this should
be merged, and a similar follow-up for serif heading fonts might also
be necessary (but that's obviously a lower-severity problem, there
isn't that much text in headings). Steven, I'm sorry, but I'm
overriding your -2.

(I'm posting this on the Gerrit change
https://gerrit.wikimedia.org/r/#/c/124475/, on the tracking bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 and in the
wikitech-l thread. Please reply on wikitech-l.)

Replicating what I wrote on the patch:

Bartosz: thanks for the considered, factual take on the matter. I
appreciate you taking the time to read up on everything though obviously I
disagree about Nimbus Sans L and Helvetica Neue not being improvements.

I would caution against being English Wikipedia centric in talking about
user acceptance of the new typography. Spanish Wikipedia is far less
aligned against it (
https://es.wikipedia.org/wiki/Wikipedia:Votaciones/2014/Sobre_la_actualizaci%C3%B3n_tipogr%C3%A1fica)
and other wikis (German, French) have declined to open a vote on the matter
while they wait for continued tweaks from us. I posted in the other thread
Erwin started about our plan for dealing with serifs in non-Latin languages.

In any case, I think this is acceptable for now since we can always submit
a new patch again later that puts a free/libre font first in addition to
the current stack being reverted. Either way we need to do more research
and testing to accomplish that, or even explore webfonts more.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users; final plea!

2014-04-11 Thread Jon Robson

It looks like Nemo has been doing this (thanks a bunch Nemo) but I
wasn't cc'ed on any of these reports so I was getting just as
frustrated as you thinking we were inside a black hole :)

I don't expect the average user to raise bugs.

This would be a great thing to discuss in the retrospective - as soon
as a beta feature stops being a beta feature, we should have flushed
the contents of the typography talk page and asked that people raise
bugs or at least we/i should have been more attentive and raised bugs
on behalf of those users to ensure that common problems could be
collated and addressed.


On Fri, Apr 11, 2014 at 11:53 AM, Erwin Dokter er...@darcoury.nl wrote:
 On 11-04-2014 20:00, Jon Robson wrote:


 Please don't accuse me of things that are not true. I do want to see
 these things, but I have to manage 1) mailing lists 2) bugzilla 3)
 wiki pages (which i have to know exist). I am only human. Thanks for
 the links to bugs I've cc'ed myself on all of these.


 That was not my intention, I'm sorry. But I am getting so frustrated because
 the foundation keeps giving the impression that it does not even acknowledge
 that there is a problem, or at least refuses to remedy it by clinging on the
 currently broken implementaion.


 Since that page was linked as the primary feedback page when the refresh
 was
 announced, it should be the first place to check for error reports.
 Claiming
 non-existence of Bugzilla reports is just plain selective ignorance.


 I disagree. Bugzilla is where we report bugs. If no one raises bugs as
 they will go lost.


 Then that should have been in the FAQ. The announcement only sends the
 readers to the talk page to give feedback.


 Regards,
 --
 Erwin Dokter


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



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Derk-Jan Hartman

I echo Brian's assessment here. Screen readers don't care about fonts.
They only look at what the semantic elements tell you.

DJ


On Thu, Apr 10, 2014 at 2:45 AM, Brian Wolff bawo...@gmail.com wrote:
 And has any testing been done with screen readers and dyslexia readers to


 I would be extremely surprised if this interacted negatively with screen
 readers. Screen readers normally dont even look at the font choice.

 --bawolff
 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Derk-Jan Hartman

My sentiment here is that all of this has supported every latent
opinion that I had about the project when it was started. Years of
maintaining templates, CSS and Javascript on English Wikipedia had
taught me not to mess with fonts unless it was very targeted
(preferring a specific font for a language fragment or class). It also
taught me that anything like this is factors worse on non-English
wiki's. I think Erwin was sharing those concerns (probably more vocal
than me) for the exact same reason. We might not have been able to
show the evidence beforehand in a nicely written document, but we knew
this was a very risqué operation.
The beta testing had sort of subdued my concerns a bit, but that
turned out to be a false sense of security.

With all the good that has happened on the web over the past 10 years,
there are simply a few areas that are hopelessly stuck in that past,
and those are mostly the areas that are very much bound to (or used to
be bound to) OS functionality. These include for instance:
Audio/Video, accessibility support and fonts !!!

There are very good reasons for why all these areas are in such a bad
shape, history, long support cycles, patents etc. Every time we have
tried to make changes in these areas, we seem to underestimate:
 1. just how far in the past many of the browser+OS configurations are
 2. how much worse 3rd party software can make the situation
 3. how inadequate the existing Free/Open alternatives are (especially
with regard to global scope/big audiences/high performance)
 4. how 'religious' our community is with regard to it's Free/Open foundations.

So for me, the question is not how can we apply pretty serif fonts to
headers, the question is what can we do short term and long term to
make that happen.
Short term:
 * Accept that the current solution is not working
 * Rely on Operating System to make the best choice it can, because we
cannot do better (return to status quo)
 * Accept that maybe it might just not be possible right now
 * Gather statistics on cleartype font rendering (just like we look at tofu).
 * See if there are ways to make the target group to which the font
change is applied narrower/stricter/better defined.

Longer term:
 * Work with font communities to build true usable, enjoyable Free
fonts with global reach.
 * Work with web/browser development communities to make web fonts
more efficient
 * Work with OS vendors to make sure they are committed to fixing
problems in/with fonts, delivering open fonts

It seems to me that those are the areas where we should focus our
attention, simply because that will allow us to get to nicely designed
pages, without running into those problems mentioned above.

DJ

On Tue, Apr 8, 2014 at 8:14 PM, Erwin Dokter er...@darcoury.nl wrote:
 On 08-04-2014 19:29, Jared Zimmerman wrote:

 I don't really have the energy to keep having this conversation, I
 appreciate that everyone has taken the time to weigh in on this whatever
 you opinion is on the matter.


 I am sorry you feel that way. But I have to make one thing clear:

 This is not an aestethic issue. This is a *technical* one.

 I do appriciate all the work the designers have done and I do believe the
 new typography is in essense very well thought out.

 However, its *technical* implementation is severy flawed.

 It has caused many non-latin projects to force them to override the global
 font stack in their local CSS to reset it to sans-serif, because parts of
 their site have become unreadable or illegible. That makes this a *breaking
 change*, and as such, *must* be reverted.

 I do not accept that there will be a few readers left with issues; our
 primary goal is legibility. And if legibility is damaged on a world-wide
 encyclopedia, how can you even *think* about defending a breaking change?

 Regards,
 --
 Erwin Dokter



 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Erik Moeller

On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
d.j.hartman+wmf...@gmail.com wrote:
So for me, the question is not how can we apply pretty serif fonts to
headers, the question is what can we do short term and long term to
make that happen.

It would be good if we could focus the conversation as much on
concrete bugs and issues as possible.

My understanding is that there are three separate major issues:

* serif may not be a good choice for certain languages, no matter what
font stack you use, because serif connotes different things in
different scripts, and the meaning that's attached to it in Latin
script may not necessarily translate well to other languages.

I don't think that's an argument against serifs, and this doesn't
negate the reasoning explained in [1] when it comes to Latin script
wikis. Rather, it argues for per-language improvements.

Disabling serif for certain languages is currently handled by local
overrides which is not ideal for obvious reasons. The only way I can
see to properly resolve that is to explicitly vary the font stack
based on the content language. Does that make sense? If so, what's the
best way to accomplish it?

* As a serif font, Georgia uses old-style numerals (whether users get
Georgia depends on their locally installed stack). Some readers aren't
used to old-style numerals, but they are really designed to flow with
Latin script, so they look especially odd with other scripts. Since,
as established in the first point, the serif specification per se
may not make sense for certain languages, this issue could be resolved
in one fell swoop by specifying sans-serif for certain
languages/scripts.

* The explicitly specified sans-serif stack needs to be further
optimized, and ideally should prioritize free/libre fonts first (as
the serif stack does). Until then, there's disagreement about whether
the current sans-serif stack represents an appropriate place from
which to improve (the UX team is arguing that it does because the
increased specificity reduces the risk of bad defaults, others argue
that it doesn't because it violates software freedom principles).

* Because of the above issues and possibly others, some people feel
that either reverting to the previous state, or generally leaving
fonts to the browser/OS while specifying broad family choices (serif /
sans-serif), would be preferable. The UX team disagrees with that, as
they feel that we can achieve a good result for the reader with higher
predictability by making specific font recommendations.

Are those the main issues? Am I misrepresenting anything or forgetting
something / additional major issues?

Thanks,
Erik

[1]
https://www.mediawiki.org/wiki/Typography_refresh#Why_are_we_using_serif_fonts_for_the_headings.3F
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Quim Gil

On Thu, Apr 10, 2014 at 9:54 AM, Erik Moeller e...@wikimedia.org wrote:

(snip)

 My understanding is that there are three separate major issues:

 * serif may not be a good choice for certain languages

 * The explicitly specified sans-serif stack needs to be further
 optimized

 * some people feel that either reverting to the previous state would be 
 preferable. The

 Are those the main issues? Am I misrepresenting anything or forgetting
 something / additional major issues?

The analysis of these points looks accurate. We could add:

* A MediaWiki Core change vs a Wikimedia specific configuration.

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Steven Walling

On Thu, Apr 10, 2014 at 12:10 PM, Quim Gil q...@wikimedia.org wrote:

 On Thu, Apr 10, 2014 at 9:54 AM, Erik Moeller e...@wikimedia.org wrote:

 (snip)

  My understanding is that there are three separate major issues:
 
  * serif may not be a good choice for certain languages

  * The explicitly specified sans-serif stack needs to be further
  optimized

  * some people feel that either reverting to the previous state would be
 preferable. The

  Are those the main issues? Am I misrepresenting anything or forgetting
  something / additional major issues?

 The analysis of these points looks accurate. We could add:

 * A MediaWiki Core change vs a Wikimedia specific configuration.


I definitely agree with Erik's summation, but I would not like to open up
discussion about Wikimedia-specific consideration vs. core, which is a
broader question about what Vector should be/do that I don't think should
block us reaching a consensus on typography in the meantime.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Steven Walling

On Wed, Apr 9, 2014 at 9:44 PM, Gerard Meijssen
gerard.meijs...@gmail.comwrote:

 Given that you do have statistics, how did all the huha around the ULS
 performance issue and now all this hit the use of the functionality for
 dyslexic people?


I'm not sure what statistics you're referring to.


 We know that it helps but how do we help people with dyslexia? They are
 only 7 to 10% of a population.. I have not done the arithmetic but would
 that be more than 7 to 10% of all our readers? (what is the breakdown in
 fonts for our total public)


In the FAQ (https://www.mediawiki.org/wiki/Typography_refresh#FAQ) we
specifically mentioned enhancing the view for dyslexic users as one of the
reasons why the body font color was changed. To go in to more detail about
other aspects... dyslexic users is one of the reasons why we did not
suggest we switch to a serif for body text along with the headers. As far
as I understand, it's also a reason to not specify a more humanist-style
sans-serif like Open Sans, Verdana, or DejaVu where the letterforms have
more calligraphic characteristics compared to a Grotesk-style sans like
Arial, Helvetica, and Nimbus.

Of course there is also the question about whether to deliver Open Dyslexic
as a webfont option via ULS. I don't know why it was removed and how that
decision was made, so I can't comment on it.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Quim Gil

On Thursday, April 10, 2014, Steven Walling steven.wall...@gmail.com
wrote:


 I definitely agree with Erik's summation, but I would not like to open up
 discussion about Wikimedia-specific consideration vs. core, which is a
 broader question about what Vector should be/do that I don't think should
 block us reaching a consensus on typography in the meantime.



Ok for the sake of simplifying the already complex discussion, but we
should still consider the fact that we have a MediaWiki 1.23 release
scheduled in few weeks.

https://www.mediawiki.org/wiki/MediaWiki_1.23#Release_Schedule

1.23.0 2014-05-29

Our 3rd party MediaWiki users (the sysadmins and their users) should not be
affected by the unstable situation around font styles. If we are going to
change their defaults, we should better do it when we are certain about the
reliability of the changes. If this certainty comes soon enough to make it
to 1.23.0, good. Otherwise, can we plan for an alternative?


-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread David Gerard

On 10 April 2014 22:16, Quim Gil q...@wikimedia.org wrote:

 Our 3rd party MediaWiki users (the sysadmins and their users) should not be
 affected by the unstable situation around font styles. If we are going to
 change their defaults, we should better do it when we are certain about the
 reliability of the changes. If this certainty comes soon enough to make it
 to 1.23.0, good. Otherwise, can we plan for an alternative?


*hand up* Speaking as one user, I'd be fine with the previous
situation, or with just sans-serif for the body, if we don't have an
excellent answer by then.


- d.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Brian Wolff

On 4/10/14, Erik Moeller e...@wikimedia.org wrote:
On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
d.j.hartman+wmf...@gmail.com wrote:
So for me, the question is not how can we apply pretty serif fonts to
headers, the question is what can we do short term and long term to
make that happen.

It would be good if we could focus the conversation as much on
concrete bugs and issues as possible.

My understanding is that there are three separate major issues:

I don't think that's an argument against serifs, and this doesn't
negate the reasoning explained in [1] when it comes to Latin script
wikis. Rather, it argues for per-language improvements.

Are those the main issues? Am I misrepresenting anything or forgetting
something / additional major issues?

Thanks,
Erik

[1]
https://www.mediawiki.org/wiki/Typography_refresh#Why_are_we_using_serif_fonts_for_the_headings.3F
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

By lower quality I mean both subjectively, but also objectively. For
example, today I was reading
https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1%27s_900th_Grand_Prix
(enwikinews is one of the few wikis I haven't overridden the font
changes with css). At first I thought there was a typo in the image
caption toward the end of the page, an extra space between prote and
stor. But no, the kerning on the font chosen is just literally that
bad, that you can't tell if it is an extra space, or just a kerning
error. I call that objectively bad (There's other things I don't like
about the font choice, but they are more touchy-feely subjective)

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread MZMcBride

Erik Moeller wrote:
On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
d.j.hartman+wmf...@gmail.com wrote:
 So for me, the question is not how can we apply pretty serif fonts to
 headers, the question is what can we do short term and long term to
 make that happen.

It would be good if we could focus the conversation as much on
concrete bugs and issues as possible.

You mean something like this?

Derk-Jan Hartman wrote:
Short term:
* Accept that the current solution is not working
* Rely on Operating System to make the best choice it can, because we
cannot do better (return to status quo)
* Accept that maybe it might just not be possible right now
* Gather statistics on cleartype font rendering (just like we look at
tofu).
* See if there are ways to make the target group to which the font
change is applied narrower/stricter/better defined.

Longer term:
* Work with font communities to build true usable, enjoyable Free
fonts with global reach.
* Work with web/browser development communities to make web fonts
more efficient
* Work with OS vendors to make sure they are committed to fixing
problems in/with fonts, delivering open fonts

I agree with all of this. Both Erik's and Derk-Jan's posts are very
good, but I get the feeling that people are talking past each other in
this thread sometimes.

As Quim notes, there's an upcoming MediaWiki release. We should merge
https://gerrit.wikimedia.org/r/124475 into master and figure out what to
do with the other font-family adjustments for the short-term.

There seems to be demonstrable consensus for merging Gerrit change 124475
into master, though Steven refuses to remove his -2, which he should never
have been able to set. If you (Erik) are truly interested in focusing the
conversation on concrete bugs and issues, that's where I would start.

MZMcBride



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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread Steven Walling

On Thursday, April 10, 2014, Steven Walling steven.wall...@gmail.com
wrote:



 On Thursday, April 10, 2014, MZMcBride z...@mzmcbride.com wrote:

 Erik Moeller wrote:
 On Thu, Apr 10, 2014 at 7:39 AM, Derk-Jan Hartman
 d.j.hartman+wmf...@gmail.com wrote:
  So for me, the question is not how can we apply pretty serif fonts to
  headers, the question is what can we do short term and long term to
  make that happen.
 
 It would be good if we could focus the conversation as much on
 concrete bugs and issues as possible.

 You mean something like this?

 Derk-Jan Hartman wrote:
 Short term:
 * Accept that the current solution is not working
 * Rely on Operating System to make the best choice it can, because we
 cannot do better (return to status quo)
 * Accept that maybe it might just not be possible right now
 * Gather statistics on cleartype font rendering (just like we look at
 tofu).
 * See if there are ways to make the target group to which the font
 change is applied narrower/stricter/better defined.
 


 How are these specific, replicable bugs? DJ is saying things the current
 solution is not working and we cannot do better but there is no
 evidence about why this is the case for such a large number of users that
 it requires a revert back to plain sans-serif.

 People are talking in generalities and about problems related to areas
 like non-Latin script support, but not referring to bugs filed and which
 would be fixed by the suggested patch. Brian's recent comment here is an
 example of what we are asking to hear, though I don't think that requires a
 full revert.

 Meanwhile, in this thread and in the documentation on mediawiki.org, we
 have been extremely specific about how each aspect of the new typography
 (including the body fonts specified) is a pragmatic improvement for users,
 and what we lose by reverting. I also posted links to that effect on the
 patch.

 The patch as it stands does not refer to an unresolved bug or enhancement.
 It also explicitly refers to the issue as an ideological one about
 potentially promoting non-free fonts in our code, even though Jon already
 out a FIXME acknowledging this.

 Unless you can raise issues that cause actual functional problems that
 outweigh the benefits of the new body font stack, I don't think merging
 that patch is required to improve things and is worth the churn in user
 experience for millions of readers.

 Steven


Sorry that Gmail mobile sent that twice. :/






 I agree with all of this. Both Erik's and Derk-Jan's posts are very
 good, but I get the feeling that people are talking past each other in
 this thread sometimes.

 As Quim notes, there's an upcoming MediaWiki release. We should merge
 https://gerrit.wikimedia.org/r/124475 into master and figure out what
 to
 do with the other font-family adjustments for the short-term.

 There seems to be demonstrable consensus for merging Gerrit change 124475
 into master, though Steven refuses to remove his -2, which he should never
 have been able to set. If you (Erik) are truly interested in focusing the
 conversation on concrete bugs and issues, that's where I would start.

 MZMcBride



 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-10 Thread John Mark Vandenberg

On Fri, Apr 11, 2014 at 6:26 AM, Brian Wolff bawo...@gmail.com wrote:
..
 By lower quality I mean both subjectively, but also objectively. For
 example, today I was reading
 https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1%27s_900th_Grand_Prix
 (enwikinews is one of the few wikis I haven't overridden the font
 changes with css). At first I thought there was a typo in the image
 caption toward the end of the page, an extra space between prote and
 stor. But no, the kerning on the font chosen is just literally that
 bad, that you can't tell if it is an extra space, or just a kerning
 error. I call that objectively bad (There's other things I don't like
 about the font choice, but they are more touchy-feely subjective)

I can reproduce this. It looks _very_ bad on Firefox/Fedora Core 19,
and but it also appears to a lesser degree on Chrome/Fedora Core 19.

Compare it against monobook

https://en.wikinews.org/wiki/Hamilton_wins_%27incredible%27_Bahrain_race,_F1%27s_900th_Grand_Prix?useskin=monobook

See also the ама in the bold title in the first sentence of

https://ru.wikipedia.org/wiki/?oldid=58319520

vs

https://ru.wikipedia.org/wiki/?oldid=58319520useskin=monobook

-- 
John Vandenberg

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Steven Walling

On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:

 It's pretty clear that the objectives of this project are not successfully
 met at this point, and in fact have caused major problems on non-Latin
 script WMF sites, and significant but less critical problems on Latin
 script sites. Several factors for this have been identified in the thread -
 including limited attention to the effects on non-Latin script projects,
 the insertion of philosophical principles (FOSS) without a clear
 understanding of the effects this would have on the outcome, and the
 unwillingness to step back when a major change results in loss of
 functionality.


[citation needed]

Loss of functionality? The functionality we're talking about here is
reading of Wikimedia content. It's the most core, most basic functionality
we have. In the case of VisualEditor, which picks up read-mode typography
styles, it's also editing.

Did reading suddenly become seriously impaired? No. If these things had
happened, you'd see a hell of a lot more outcry than what we've seen now.
If millions of readers and tens of thousands of editors were functionally
unable to read our content easily and smoothly, you would hear a lot more
complaints. If you didn't hear complaints, you'd probably still see a swift
drop in pageviews.[1]

Instead, what I see is this: a tiny handful of bugs raised.[2] I also see a
relatively small number of editors complaining on Village Pumps -- we have
75,000+ contributors a month. 137 of them have showed up to complain in
English so far, our largest project. Fewer in other languages. Does that
suggest to you most of our editors are having serious functional issues
reading, particularly when we had 14,000 registered users voluntarily
opt-in to the changes? For reader feedback: comments from readers (on-wiki
and off) have slowed significantly in the days since the change was
made.[3] The same look has been in place on mobile (20% of our traffic) for
more than a year with basically zero complaints.

This is the first time we've significantly changed Wikimedia typography in
many years. I do not under any circumstances suggest that everything has
gone forward with perfect smoothness. I also 100% agree it can and should
continue to improve.[4] Particularly, I agree that in the immediate future
we need to pay more attention to non-Latin wikis, though everyone keeps
saying major problems without actually being specific about what bugs
there are, which doesn't really help constructively. I also would prefer to
find a freely-licensed font to put first in the stack again, as soon as we
can get one that doesn't cause bugs for users on Windows systems. But to
suggest the project was a failure and that is serious loss of reading
functionality is just untrue and frankly hyperbolic.

Steven

1. Our realtime pageviews data is lacking, but HTTP requests and edit rates
for top wikis via gdash.wikimedia.org don't seem to show unusual drops. Am
I wrong?
2. See https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 for tracking.
Only four are open, and they pretty minor.
3.
https://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback/font_sizeas
an example had many comments the first two days. As of today and
yesterday, there are a tiny handful. OTRS has not even had enough comments
to warrant creating a template response. And the number of tweets and
Facebook comments has died down to almost nothing.
4. We're going to hold a retrospective on the process around this change
later next week. That will include a public wiki page with more opportunity
for people to suggest ways the general process of Beta Features
testing/graduation can be handled better.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread John Mark Vandenberg

On Apr 9, 2014 2:02 PM, Steven Walling steven.wall...@gmail.com wrote:

 On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:

  It's pretty clear that the objectives of this project are not
successfully
  met at this point, and in fact have caused major problems on non-Latin
  script WMF sites, and significant but less critical problems on Latin
  script sites. Several factors for this have been identified in the
thread -
  including limited attention to the effects on non-Latin script projects,
  the insertion of philosophical principles (FOSS) without a clear
  understanding of the effects this would have on the outcome, and the
  unwillingness to step back when a major change results in loss of
  functionality.
 

 [citation needed]

 Loss of functionality? The functionality we're talking about here is
 reading of Wikimedia content. It's the most core, most basic functionality
 we have. In the case of VisualEditor, which picks up read-mode typography
 styles, it's also editing.

 Did reading suddenly become seriously impaired? No.

Yes, it was seriously impaired. On the scale of impairments possible with a
font stack change, compared to how it was, this change was in the high end
of the scale, next to broken.

I currently visit a lot of language pedias doing category linking on
wikidata, and after the change I noticed many had obviously bad font issues
that I didnt see the day before. Clicking random on a few wikis would have
been enough testing to work that out.

Btw that was using Chrome on Fedora Core 19 without any local mods to font
handling.

The functionality was previously fine. Maybe it could be improved, but that
isnt what happened.

I agree with everything Risker said. I go further and suggest the team
involved stops defending their goals and implementation. The former are not
the issue, and the latter was indefensible. I havent looked at how much
testing was done, or if there was some staging of the rollout, but it is
clear that it wasnt careful enough.

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

Re: [Wikitech-l] Free fonts and Windows users

On 9 April 2014 09:26, John Mark Vandenberg jay...@gmail.com wrote:

  I havent looked at how much
 testing was done, or if there was some staging of the rollout, but it is
 clear that it wasnt careful enough.


To be fair, it's easy to say that in hindsight. But e.g. who knew so
many people were running Windows with ClearType off, and that these
fonts rendered so badly under it? I mean *now* we know to look at that
specific thing :-)


- d.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread John Mark Vandenberg

On Wed, Apr 9, 2014 at 5:06 PM, David Gerard dger...@gmail.com wrote:
 On 9 April 2014 09:26, John Mark Vandenberg jay...@gmail.com wrote:

  I havent looked at how much
 testing was done, or if there was some staging of the rollout, but it is
 clear that it wasnt careful enough.


 To be fair, it's easy to say that in hindsight. But e.g. who knew so
 many people were running Windows with ClearType off, and that these
 fonts rendered so badly under it? I mean *now* we know to look at that
 specific thing :-)

Did you even read my email?

-- 
John Vandenberg

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

Re: [Wikitech-l] Free fonts and Windows users

On 9 April 2014 11:16, John Mark Vandenberg jay...@gmail.com wrote:

 Did you even read my email?



Yes, I was responding to just that part.


- d.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Isarra Yos


On 09/04/14 08:26, John Mark Vandenberg wrote:

I agree with everything Risker said. I go further and suggest the team
involved stops defending their goals and implementation. The former are not
the issue, and the latter was indefensible. I havent looked at how much
testing was done, or if there was some staging of the rollout, but it is
clear that it wasnt careful enough.


While I agree in general, I'm not even sure about that, that the goals 
weren't the issue - do we even know what the goals /were/, or the issues 
that they were trying to address? I've asked, and seen others ask, 
several times in multiple venues, and I've yet to see a real answer. The 
most anyone has been able to produce (usually Steven, I think, so I'll 
thank him for at least trying) have been things like that it looks 
better or it's more consistent, but that would be like a security person 
only saying their change makes things more secure, and explaining 
'because security' in the commit message. Sure, it might be true, but 
it's completely useless if you're trying to work with it, or test it 
exhaustively. We need to know what the issue really was, too, or we 
can't possibly have any real discussion or collaboration. With security, 
it's communicated - we just saw that with announcements of the 
heartbleed exploit. Why isn't it with design?


So, yeah, the goals are probably noble enough, but we don't even know 
that for sure. There's a gulf here, and it's just getting worse.


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Tim Landscheidt

Steven Walling steven.wall...@gmail.com wrote:

 It's pretty clear that the objectives of this project are not successfully
 met at this point, and in fact have caused major problems on non-Latin
 script WMF sites, and significant but less critical problems on Latin
 script sites. Several factors for this have been identified in the thread -
 including limited attention to the effects on non-Latin script projects,
 the insertion of philosophical principles (FOSS) without a clear
 understanding of the effects this would have on the outcome, and the
 unwillingness to step back when a major change results in loss of
 functionality.

 [citation needed]

 Loss of functionality? The functionality we're talking about here is
 reading of Wikimedia content. It's the most core, most basic functionality
 we have. In the case of VisualEditor, which picks up read-mode typography
 styles, it's also editing.

 Did reading suddenly become seriously impaired? No. If these things had
 happened, you'd see a hell of a lot more outcry than what we've seen now.
 If millions of readers and tens of thousands of editors were functionally
 unable to read our content easily and smoothly, you would hear a lot more
 complaints. If you didn't hear complaints, you'd probably still see a swift
 drop in pageviews.[1]

 [...]

 1. Our realtime pageviews data is lacking, but HTTP requests and edit rates
 for top wikis via gdash.wikimedia.org don't seem to show unusual drops. Am
 I wrong?
 [...]

What other free encyclopaedia would you expect readers and
editors to turn to?

Tim


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Nathan

On Wed, Apr 9, 2014 at 1:05 AM, Risker risker...@gmail.com wrote:
snip


 There is a bit of amnesia about the fact that almost all editors are also
 readers and regular users of the projects we create, and those editors have
 been encouraged since Day One to inform developers of any technical
 problems with the site; they're the canaries in the coal mine.  And for
 anyone who's been editing more than 3-4 years (an ever-increasing
 percentage of the editing community), software issues were things they
 had to pretty much solve themselves within the volunteer community. For
 years, most developers were volunteers too, and had close links to the
 editing community.  At least a good portion of you remember those days -
 because you used to be those volunteer developers that community members
 would hit up to fix things, and you used to watch the village pumps to
 figure out what else needed to be fixed. Until very recently, it was almost
 unheard-of for community members to be told that problematic things were
 going to stay that way because of a decision made by a small number of
 people in an office somewhere.  When most developers were clearly
 participating as community members, they behaved as though they were, at
 least to a significant extent, accountable to both the editing and
 Mediawiki communities; I'm not sure that sense of accountability exists
 anymore.  Now, I don't think anyone begrudges the many talented developers
 who started off within the community having taken the opportunity to move
 on to paid positions at the WMF, and I think on the whole the big-picture
 community is overall very happy with the majority of changes that have come
 with the increased professionalization of the site engineering and
 operations.  But this is a major change in culture, and the gulf between
 volunteers (either developer or editor) and WMF staff is widening
 noticeably as time progresses.  I could tell who was a volunteer and who
 was staff from the way their posts were responded to in this thread; I
 doubt that would have been the case even two years ago.

 snip

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



Which gulf is growing more quickly - between the WMF staff and volunteers,
or between the veteran editing population and the typical reader? I won't
argue that there is some distance, and a degree of conflict, between the
goals and priorities of the staff and many veteran volunteers. But this
distance hasn't occurred organically. It's been introduced consciously, and
mentioned on a number of occasions, by WMF leaders like Sue and Erik. They
have often made the point that the WMF has to consider first the hundreds
of millions of readers who compose our intended audience.

No one has said, that I've seen, that complaints and problems from the
editing community should be ignored. But I think Steve and Jon are
struggling with how to react to complaints without knowing how
representative they are of the reader experience. If complaints are
presented by a tiny percentage of the editing community, how many should
they assume are encountering the problem but not reporting it? If
readership numbers don't change, and people who login to complain are
definitionally lumped into editors, how do we assess the impact on
readers and whether or not many readers are having difficulty?

These aren't easy questions to answer. Many people complaining about this
change, and others, seem to make different automatic assumptions about
relevance and impact than the WMF staff, or they don't consider it at all.
To be fair to the engineering staff, we should keep in mind that they have
to relate complaints from developers and editors to the experience of
hundreds of millions of readers and make decisions principally (but not
wholly) based on the latter, not the former.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Risker

Interestingly, but probably completely unrelated, I note that one of the
options on your first reference [Varnish: Pageviews By Top Wikis] shows a
drop to zero in page views at around 0625 hours UTC today. Of course, the
view only gives an 8 hour snapshot, so it's not possible for an ordinary
person like me to compare before and after changeover.  However, that
page won't load for me now for some reason so there's little else I can say
here.

My evidence that there is degradation is fairly simple: Prior to this
change, some users might not like the font they were getting, but no
matter the project or OS/browser the user was using, the fonts rendered
properly.  Now, that is no longer consistently the case. If they have made
certain modifications to their font defaults for reasons other interfacing
with Wikipedia, or they are using non-latin scripts, their Wiki(p)(m)edia
viewing experience has a good chance of being negatively altered.

Personally, I don't care all that much whether headers and body are two
different fonts, although serif fonts always look old-fashioned and dated
to me, especially if they include the lorgnette-shaped g. (Those of you
who have met me will appreciate the irony in that statement.)  The issue
remains the viewability across all of our hundreds of platforms, and that
seems to keep coming back to the new forced font stack.  This is the issue,
not whether or not typography should be updated.  When non-Latin projects
feel the need to override such a major update because of usability and
readibility issues, there's a major problem here.  Just because they aren't
English Wikipedia doesn't mean their issues are minor, and they have the
disadvantage of a language barrier to make their problems known.

Risker/Anne




On 9 April 2014 03:01, Steven Walling steven.wall...@gmail.com wrote:

 On Tue, Apr 8, 2014 at 10:05 PM, Risker risker...@gmail.com wrote:

  It's pretty clear that the objectives of this project are not
 successfully
  met at this point, and in fact have caused major problems on non-Latin
  script WMF sites, and significant but less critical problems on Latin
  script sites. Several factors for this have been identified in the
 thread -
  including limited attention to the effects on non-Latin script projects,
  the insertion of philosophical principles (FOSS) without a clear
  understanding of the effects this would have on the outcome, and the
  unwillingness to step back when a major change results in loss of
  functionality.
 

 [citation needed]

 Loss of functionality? The functionality we're talking about here is
 reading of Wikimedia content. It's the most core, most basic functionality
 we have. In the case of VisualEditor, which picks up read-mode typography
 styles, it's also editing.

 Did reading suddenly become seriously impaired? No. If these things had
 happened, you'd see a hell of a lot more outcry than what we've seen now.
 If millions of readers and tens of thousands of editors were functionally
 unable to read our content easily and smoothly, you would hear a lot more
 complaints. If you didn't hear complaints, you'd probably still see a swift
 drop in pageviews.[1]

 Instead, what I see is this: a tiny handful of bugs raised.[2] I also see a
 relatively small number of editors complaining on Village Pumps -- we have
 75,000+ contributors a month. 137 of them have showed up to complain in
 English so far, our largest project. Fewer in other languages. Does that
 suggest to you most of our editors are having serious functional issues
 reading, particularly when we had 14,000 registered users voluntarily
 opt-in to the changes? For reader feedback: comments from readers (on-wiki
 and off) have slowed significantly in the days since the change was
 made.[3] The same look has been in place on mobile (20% of our traffic) for
 more than a year with basically zero complaints.

 This is the first time we've significantly changed Wikimedia typography in
 many years. I do not under any circumstances suggest that everything has
 gone forward with perfect smoothness. I also 100% agree it can and should
 continue to improve.[4] Particularly, I agree that in the immediate future
 we need to pay more attention to non-Latin wikis, though everyone keeps
 saying major problems without actually being specific about what bugs
 there are, which doesn't really help constructively. I also would prefer to
 find a freely-licensed font to put first in the stack again, as soon as we
 can get one that doesn't cause bugs for users on Windows systems. But to
 suggest the project was a failure and that is serious loss of reading
 functionality is just untrue and frankly hyperbolic.

 Steven

 1. Our realtime pageviews data is lacking, but HTTP requests and edit rates
 for top wikis via gdash.wikimedia.org don't seem to show unusual drops. Am
 I wrong?
 2. See https://bugzilla.wikimedia.org/show_bug.cgi?id=63549 for tracking.
 Only four are open, and they pretty minor.
 3.

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Brian Wolff



 Which gulf is growing more quickly - between the WMF staff and volunteers,
 or between the veteran editing population and the typical reader? I won't
 argue that there is some distance, and a degree of conflict, between the
 goals and priorities of the staff and many veteran volunteers. But this
 distance hasn't occurred organically. It's been introduced consciously, and
 mentioned on a number of occasions, by WMF leaders like Sue and Erik. They
 have often made the point that the WMF has to consider first the hundreds
 of millions of readers who compose our intended audience.

 No one has said, that I've seen, that complaints and problems from the
 editing community should be ignored. But I think Steve and Jon are
 struggling with how to react to complaints without knowing how
 representative they are of the reader experience. If complaints are
 presented by a tiny percentage of the editing community, how many should
 they assume are encountering the problem but not reporting it? If
 readership numbers don't change, and people who login to complain are
 definitionally lumped into editors, how do we assess the impact on
 readers and whether or not many readers are having difficulty?

 These aren't easy questions to answer. Many people complaining about this
 change, and others, seem to make different automatic assumptions about
 relevance and impact than the WMF staff, or they don't consider it at all.
 To be fair to the engineering staff, we should keep in mind that they have
 to relate complaints from developers and editors to the experience of
 hundreds of millions of readers and make decisions principally (but not
 wholly) based on the latter, not the former.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l


To be honest, I'm kind of tired of hearing, won't anyone think of the
readers as an excuse to do pretty much anything. Most of the time
(not all the time) I've seen that excuse be used, there isn't any
evidence about how the change actually affects the readers except for
the authors' own conjecture (Or if they do have evidence, they largely
aren't communicating it very well). Readers generally don't complain
when something changes for the worse, unless it really changes for the
worse (e.g. Site going down). Even if the readers did complain in the
same way our users do, taking a lack of complaints to mean something
is a positive improvement, seems like a recipe for confirmation bias.

That said, we shouldn't be afraid of making changes where we
reasonably think they might be a good idea, even without evidence they
actually are. You can't have data on everything. I just don't like
Well we are undoubtedly making things better for the reader used as
a counter argument to criticism when we simply don't know what it will
do for the average reader.

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:

 That said, we shouldn't be afraid of making changes where we
 reasonably think they might be a good idea, even without evidence they
 actually are. You can't have data on everything. I just don't like
 Well we are undoubtedly making things better for the reader used as
 a counter argument to criticism when we simply don't know what it will
 do for the average reader.



Yes, it is the sort of statement that probably should not be used
without being followed by a link to actual UI testing results.


- d.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Steven Walling

On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dger...@gmail.com wrote:

 On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:

  That said, we shouldn't be afraid of making changes where we
  reasonably think they might be a good idea, even without evidence they
  actually are. You can't have data on everything. I just don't like
  Well we are undoubtedly making things better for the reader used as
  a counter argument to criticism when we simply don't know what it will
  do for the average reader.



 Yes, it is the sort of statement that probably should not be used
 without being followed by a link to actual UI testing results.


I should follow up on this and say that no one working on the Beta Feature
thinks it's a good idea to try and design typography that only works for
people who aren't logged in/don't edit. The design goals listed at
http://blog.wikimedia.org/2014/03/27/typography-refresh/ and
https://www.mediawiki.org/wiki/Typography_refresh#Summary_of_changes are
pretty universal to all users, as they should be.

I don't really think that when it comes to typography, either type of
visitor to Wikimedia sites is more or less important when it comes to
listening to feedback. Even if Nathan was right, sometimes it's hard for us
to balance the two. What I said in reply to Risker is that I don't think
there saying the change is a failure is fair or true, based on the level
and kind of feedback we've been getting from both readers *and* editors.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Risker

On 9 April 2014 14:07, Steven Walling steven.wall...@gmail.com wrote:

 On Wed, Apr 9, 2014 at 9:33 AM, David Gerard dger...@gmail.com wrote:

  On 9 April 2014 17:30, Brian Wolff bawo...@gmail.com wrote:
 
   That said, we shouldn't be afraid of making changes where we
   reasonably think they might be a good idea, even without evidence they
   actually are. You can't have data on everything. I just don't like
   Well we are undoubtedly making things better for the reader used as
   a counter argument to criticism when we simply don't know what it will
   do for the average reader.
 
 
 
  Yes, it is the sort of statement that probably should not be used
  without being followed by a link to actual UI testing results.


 I should follow up on this and say that no one working on the Beta Feature
 thinks it's a good idea to try and design typography that only works for
 people who aren't logged in/don't edit. The design goals listed at
 http://blog.wikimedia.org/2014/03/27/typography-refresh/ and
 https://www.mediawiki.org/wiki/Typography_refresh#Summary_of_changes are
 pretty universal to all users, as they should be.

 I don't really think that when it comes to typography, either type of
 visitor to Wikimedia sites is more or less important when it comes to
 listening to feedback. Even if Nathan was right, sometimes it's hard for us
 to balance the two. What I said in reply to Risker is that I don't think
 there saying the change is a failure is fair or true, based on the level
 and kind of feedback we've been getting from both readers *and* editors.




Nobody, as best I can tell, has suggested that there be two different
typographies, one for logged-in viewing and one for logged-out viewing.

Referring to the 4 points on the blog: I'm not certain why there's an urge
to have consistency between the mobile and desktop versions; I can't think
of a single mobile site I use that is truly consistent with its desktop
version.  However, I don't object to it fundamentally, and I think this was
pretty much achieved, at least for English. However, given that we do not
have reports of typography failures on mobile that we know exist for
non-latin scripts on English, consistency doesn't seem to be met.

 However, it's pretty obvious that there was a failure at #1, since the
type didn't work properly on a whole pile of regularly used WMF scripts.
We've all seen plenty of screenshots that showed what we can politely call
a failure to be beautiful in certain configurations for latin-based
scripts, as well; I suppose that would be a combination of points #1 and #3.

And has any testing been done with screen readers and dyslexia readers to
test #4?  I've not seen any reports of that.   We do have some regular
users of screen readers who would probably have been right there letting
you know if there was a conflict.  I have some anecdotal info that it does
not interact well with at least one dyslexia reader, but no further
details, and the user wouldn't provide me with a screenshot that I could
share. Nonetheless, the evidence is lacking that this was tested for; if
it's a principle goal, this needs to be done.

So... that sums up to three of the four goals not being met, and one having
no evidence that it was met.  This first release was a failure.  That is
okay; learn from it, but before you go further you must first restore the
initial functionality to the projects that have identified problems...and
any others that seem to have problems, even if they haven't told you about
it.  Someone should be checking them. Once you've returned their
functionality, make fixing those issues in the typography upgrade the
priority for subsequent releases.  That is failing successfully.

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

Re: [Wikitech-l] Free fonts and Windows users

On 9 April 2014 19:36, Risker risker...@gmail.com wrote:

 And has any testing been done with screen readers and dyslexia readers to
 test #4?  I've not seen any reports of that.   We do have some regular
 users of screen readers who would probably have been right there letting
 you know if there was a conflict.  I have some anecdotal info that it does
 not interact well with at least one dyslexia reader, but no further
 details, and the user wouldn't provide me with a screenshot that I could
 share. Nonetheless, the evidence is lacking that this was tested for; if
 it's a principle goal, this needs to be done.


Just wondering - are the user testing results up anywhere?

(And btw, is there any way user testing can be distributed, so
interested parties can participate? That might save a lot of later
angst and catch edge cases. I realise I may just have said simple
matter of programming.)


- d.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-09 Thread Gerard Meijssen

Hoi,
Given that you do have statistics, how did all the huha around the ULS
performance issue and now all this hit the use of the functionality for
dyslexic people?

We know that it helps but how do we help people with dyslexia? They are
only 7 to 10% of a population.. I have not done the arithmetic but would
that be more than 7 to 10% of all our readers? (what is the breakdown in
fonts for our total public)
Thanks,
  GerardM


On 10 April 2014 02:45, Brian Wolff bawo...@gmail.com wrote:

  And has any testing been done with screen readers and dyslexia readers to
 

 I would be extremely surprised if this interacted negatively with screen
 readers. Screen readers normally dont even look at the font choice.

 --bawolff
 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread S Page

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
Legoktm claims There was a consensus that listing only non-free fonts was
not acceptable, that's not my recollection.  Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug
63512.  Now as I understand it, we're back to:
* Mac users get Helvetica Neue
* Windows users get Arial unless they have Helvetica Neue (unlikely) or
Helvetica (I can't reproduce bug 63662)
* Linux users get whatever F/OSS font fontconfig supplies for the
well-known string Helvetica, I get Nimbus Sans L
* Android users ?? (Nobody responded.)

quoting Isarra Yos


 Given that no objective and verifiable issues with this were ever provided
 ... Why? All this effort, and for what?


BECAUSE DESIGN. (I begged and pleaded with the talented designers who work
next to me to put something emphatic in the Typography refresh FAQ.) It's a
better design. It makes MediaWiki web sites look better for millions of our
users by mentioning proprietary fonts that 90+% of them have. That's not
objective and verifiable, it just is. Is it worth mentioning non-free
fonts?  People disagree. But I'm saddened by the implicit and overt
hostility towards the art of design here (its debatable whether this
actually represents progress, it seems like things have shifted more to
managers at WMF make the decisions, etc.).

Regards,
-- 
=S Page  Features engineer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

On Apr 8, 2014 3:46 AM, Steven Walling steven.wall...@gmail.com wrote:

 On Mon, Apr 7, 2014 at 5:40 PM, MZMcBride z...@mzmcbride.com wrote:

  I've read through this thread and I've formulated two questions:
 
  * Is there consensus to specify font-family: 'Helvetica Neue',
Helvetica,
  Arial, sans-serif; in MediaWiki core?
 

 I am going to be annoying and answer your question with a question:
 consensus among who? How do make a decision like this?

 On the one hand, you have Wikimedia users, who don't really care about the
 appearance of promoting FOSS or not. They just want to things to work and
 look good. They also believe that the only consensus that matters is the
 one on their local wiki. They could honestly care less what the
 conglomeration of volunteer and staff developers think their internal
 consensus is. And mostly, even when something is a consensus decision
based
 on an RFC/discussion, the Wikimedia Foundation gets the blame (as we
 should).

Is the above the group amongst who you think there is consensus to go with
font stack font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif; ?
It seems a rather nebulous group. Are you sure there is consensus amongst
them, or could it reflect wishful thinking of what you're pretty sure they
must agree with.

Also, I doubt that this entire group doesn't care about specifying non free
fonts. If you hand-wave the group that does away, that leads to circular
reasoning that the group that doesn't care about specifying non free fonts
really doesn't care if non free fonts are specified. That doesnt tell us
much.

I'm starting to doubt there is any group of people that you're not willing
to dismiss the opinion of because the have the wrong opinion and we
shouldn't listen to them on the issue of non free fonts.


 On the other hand, we have MediaWiki developers, some of whom would rather
 throw up their hands and not specify a real font stack, rather than touch
 the non-free fonts *most users already have* with a ten foot pole. They
 seem to think that an RFC or discussion on Wikitech-l is what represents a
 consensus that must be respected. And they don't feel responsible for what
 gets released on Wikimedia sites necessarily.

 We can gain more consistent, accessible typography across languages with
an
 iterative approach that continues to build on what we've done over the
last
 five months. Or we can go back to the drawing board to try and please
 everyone, which is an impossibility if you ever want to make progress.


  * Is there an issue with specifying font-family: sans-serif; in
  MediaWiki core?
 

 Do you mean just for body type as Odder proposed in
 https://gerrit.wikimedia.org/r/#/c/124475/, or for everything?

 Steven
 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Brian Wolff

On 4/8/14, S Page sp...@wikimedia.org wrote:
 In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
 Legoktm claims There was a consensus that listing only non-free fonts was
 not acceptable, that's not my recollection.  Was a bug ever filed?

 Kaldari valiantly tried to put non-free fonts first, that caused bug
 63512.  Now as I understand it, we're back to:
 * Mac users get Helvetica Neue
 * Windows users get Arial unless they have Helvetica Neue (unlikely) or
 Helvetica (I can't reproduce bug 63662)
 * Linux users get whatever F/OSS font fontconfig supplies for the
 well-known string Helvetica, I get Nimbus Sans L
 * Android users ?? (Nobody responded.)

 quoting Isarra Yos


 Given that no objective and verifiable issues with this were ever provided
 ... Why? All this effort, and for what?


 BECAUSE DESIGN. (I begged and pleaded with the talented designers who work
 next to me to put something emphatic in the Typography refresh FAQ.) It's a
 better design. It makes MediaWiki web sites look better for millions of our
 users by mentioning proprietary fonts that 90+% of them have. That's not
 objective and verifiable, it just is. Is it worth mentioning non-free
 fonts?  People disagree. But I'm saddened by the implicit and overt
 hostility towards the art of design here (its debatable whether this
 actually represents progress,

How is that hostile to the art of design. I have no problem with
what the typo refresh project set out to do. I have a problem with
what it actually did. I'm totally fine with the art of design as an
abstract idea and I agree with 3 of the 4 stated requirements of Typo
refresh (neutral on the consistency requirement).

 it seems like things have shifted more to
 managers at WMF make the decisions, etc.).

To clarify I never said that was necessarily a bad thing. Maybe it is,
maybe it isn't. All I'm saying is that seems to be the direction we're
heading. Heck in the context I was arguing for the side of typography
refresh...

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter


On 08-04-2014 05:01, Ori Livneh wrote:


Erwin, can you help me understand what is a suitable localization
mechanism? I filed bug 59983 (Investigate noto font as potential
replacement for diverse font families) back in January because I thought
it could help with localization, so I'd really like to grok this.


Dumping Noto in the main font stack is not going to work as each Noto 
font is geared toward displaying a specific script. What I mean by 
'mechanism' is not unlike ULS webfonts, which serves the appropriate 
font depending on the user agents requested language.


Noto is unsuitable in the context of this typography refresh (unless the 
refresh itrself will incorporate a similair mechanism).


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter


On 08-04-2014 03:25, Steven Walling wrote:


I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif
headings...


I know that Japanese Wikipedia has reset [1] their font stack entirely 
one day after the refresh.


[1] 
https://ja.wikipedia.org/w/index.php?title=MediaWiki:Vector.cssdiff=51273586oldid=46047818


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Isarra Yos


On 08/04/14 06:57, S Page wrote:

In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
Legoktm claims There was a consensus that listing only non-free fonts was
not acceptable, that's not my recollection.  Was a bug ever filed?

Kaldari valiantly tried to put non-free fonts first, that caused bug
63512.  Now as I understand it, we're back to:
* Mac users get Helvetica Neue
* Windows users get Arial unless they have Helvetica Neue (unlikely) or
Helvetica (I can't reproduce bug 63662)
* Linux users get whatever F/OSS font fontconfig supplies for the
well-known string Helvetica, I get Nimbus Sans L
* Android users ?? (Nobody responded.)


Linux often gets arial. Anyone with wine will probably have it 
installed, too, and most will have wine even if they don't use it. It's 
not necessarily a particularly good copy, either.



quoting Isarra Yos



Given that no objective and verifiable issues with this were ever provided
... Why? All this effort, and for what?


BECAUSE DESIGN. (I begged and pleaded with the talented designers who work
next to me to put something emphatic in the Typography refresh FAQ.) It's a
better design. It makes MediaWiki web sites look better for millions of our
users by mentioning proprietary fonts that 90+% of them have. That's not
objective and verifiable, it just is. Is it worth mentioning non-free
fonts?  People disagree. But I'm saddened by the implicit and overt
hostility towards the art of design here (its debatable whether this
actually represents progress, it seems like things have shifted more to
managers at WMF make the decisions, etc.).


Saying something is 'better' doesn't make it so. There are real reasons 
behind why anything is better than something else, or it would not be 
better. Even art in general is not purely subjective; if it were, we 
wouldn't hire artists and designers at all because it would be just as 
subjective to them and everyone would have different views and it'd just 
be hopeless.


Good design is good because it plays to the way our brains work. Even 
without a background in neuroscience, artists and designers learn over 
time what works and why, and they often take classes to enumerate the 
concepts as well. These are concepts they should be referring to here, 
things about the composition, the contrast, the use of space, the 
interplay between the colours. You can't just say this painting did this 
'because design' and expect anyone to take you seriously. You can, 
however, say that the added negative space helps to emphasise the 
subject, drawing attention away from that place in the background where 
someone punched a hole through the canvas. They may still not take you 
seriously because then they know you punched a hole in the canvas, but 
it's a real, understandable reason.


But there's more that needs to go into something like this beyond just 
the general principles of design - this isn't a painting, but a thing 
that people use. So what of the users themselves? What of the languages 
that it will be in, the disabilities that need to be accommodated, the 
hardware on which it will be displayed, the software that will be 
rendering it to the end user, and the principles we uphold? How is it 
better in these respects, and for these?


'Just is' doesn't fly. There is so much more to design than that, and to 
suggest otherwise discredits those who make it their passion.


-I

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jared Zimmerman

I don't really have the energy to keep having this conversation, I
appreciate that everyone has taken the time to weigh in on this whatever
you opinion is on the matter.

From Issara...
 * Windows users got fonts optimised for Windows, and which Windows
   knows well how to render. They may not be free, but /we/ weren't the
   ones prioritising the non-free.
 * Linux users got whatever (probably free) font their distribution
   provides, for which in all likelihood their fontconfig (rendering
   settings) is also optimised.
 * Those with cleartype etc off previously had fonts that rendered
   properly or they would not have been using their system with
   cleartype etc off for all this time.
 * Anyone previously using free fonts, on whatever platform, did not
   have their choices overridden. This also applies to those using
   dyslexic-friendly and other accessibility-oriented fonts.

From S Page
* Mac users get Helvetica Neue
* Windows users get Arial unless they have Helvetica Neue (unlikely) or
Helvetica (I can't reproduce bug 63662)
* Linux users get whatever F/OSS font fontconfig supplies for the
well-known string Helvetica, I get Nimbus Sans L


With the changes from Jon's patch removing Arimo and Liberation Sans, the
current font stack renders very closely to what it was originally for
Windows, and is improved for Mac and Linux users. For anyone on any
platform who has made the decision to have helvetica on their machine they
get an experience which is more consistent across devices, and platforms.

We said from day one that their might be some issues for a few non-latin
scripts, and we've reached out to the admins of those sites to help them
make small tweaks, as of jon's patch no one has provided us with any
screenshots which highlight the issues that have been mentioned from this
thread, I would welcome those screenshots as well as comments from users
fluent in the languages to comment on the matter.

I understand if you don't like it there are a lot of things I don't like
too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes
we have to learn to get used to things when they change. The thing that
confuses me, is that someone would go so far as to try to prohibit others
from doing their job based on their subjective opinion. Do product and
design people go and -2 developers patches when they don't agree on the
choices they've made? They do not. Do you know why? Its because we trust
them to make good decision based on the acceptance of their knowledge of
their domain. Why is Design different? Why does everyone think they have
equal say when it comes to aesthetic choices, its a good question, one I
don't think I'll try to answer here, but I think the gist of it is that
everyone has opinions, everyone says I could have done that whether they
could or not, whether they did or not.

We try as much as we can, with our limited time, and limited resources to
validate our decisions in a measurable way. Sometimes this isn't possible,
sometimes things are immeasurable. Does this mean that we shouldn't do
them? No, it does not.

The question was asked, why do we spend so much time on this when there are
other pressing matters to attend to. The answer is simple, because of this
process, this discourse where every decision is questioned, because a
process that should take a month takes six. I honestly want to move on to
tackle other problems, but if everything that my team or the product teams
work on comes up for a vote, it questioned to this degree, nothing will
happen, nothing will improve.

I'm tired of fighting over this, I'd like to move on, and moving on does
not mean going on to the status quo.





*Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

M : +1 415 609 4043 |   :  @JaredZimmermanhttps://twitter.com/JaredZimmerman



On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhoris...@gmail.com wrote:

 On 08/04/14 06:57, S Page wrote:

 In https://gerrit.wikimedia.org/r/#/c/124475/ (go back to sans-serif)
 Legoktm claims There was a consensus that listing only non-free fonts was
 not acceptable, that's not my recollection.  Was a bug ever filed?

 Kaldari valiantly tried to put non-free fonts first, that caused bug
 63512.  Now as I understand it, we're back to:
 * Mac users get Helvetica Neue
 * Windows users get Arial unless they have Helvetica Neue (unlikely) or
 Helvetica (I can't reproduce bug 63662)
 * Linux users get whatever F/OSS font fontconfig supplies for the
 well-known string Helvetica, I get Nimbus Sans L
 * Android users ?? (Nobody responded.)


 Linux often gets arial. Anyone with wine will probably have it installed,
 too, and most will have wine even if they don't use it. It's not
 necessarily a particularly good copy, either.


  quoting Isarra Yos


  Given that no objective and verifiable issues with this were ever
 provided
 ... Why? All this effort, and for what?

  BECAUSE DESIGN. (I begged and pleaded with the talented designers who

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Tomasz W . Kozlowski

Jared Zimmerman writes:

 I'm tired of fighting over this, I'd like to move on, and moving on does
 not mean going on to the status quo.

The status quo has been thoroughly tested by 400 million viewers a month, for 
46 months (June 2010-March 2014; ); it is a flexible and elegant solution 
that leaves the choice of the exact font up to the reader's software, as 
already explained by Isarra.

I'm tired of having https://gerrit.wikimedia.org/r/#/c/124475/ blocked for no 
good reason at all, when five people have already +1'd (how many other 
patches have you seen like that?). 

Steven has essentially said that we're /temporarily/ reverting to a setting 
that is know to work over his dead body; we don't need you to take the same 
approach, too.

Or, alternatively, please do explain here why setting font-family to sans-
serif is disruptive, sub-standard and generally not a bright idea.

Tomasz


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

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 7:29 PM, Jared Zimmerman 
jared.zimmer...@wikimedia.org wrote:

 I don't really have the energy to keep having this conversation, I
 appreciate that everyone has taken the time to weigh in on this whatever
 you opinion is on the matter.

 From Issara...
  * Windows users got fonts optimised for Windows, and which Windows
knows well how to render. They may not be free, but /we/ weren't the
ones prioritising the non-free.
  * Linux users got whatever (probably free) font their distribution
provides, for which in all likelihood their fontconfig (rendering
settings) is also optimised.
  * Those with cleartype etc off previously had fonts that rendered
properly or they would not have been using their system with
cleartype etc off for all this time.
  * Anyone previously using free fonts, on whatever platform, did not
have their choices overridden. This also applies to those using
dyslexic-friendly and other accessibility-oriented fonts.

 From S Page
 * Mac users get Helvetica Neue
 * Windows users get Arial unless they have Helvetica Neue (unlikely) or
 Helvetica (I can't reproduce bug 63662)
 * Linux users get whatever F/OSS font fontconfig supplies for the
 well-known string Helvetica, I get Nimbus Sans L


 With the changes from Jon's patch removing Arimo and Liberation Sans, the
 current font stack renders very closely to what it was originally for
 Windows, and is improved for Mac and Linux users. For anyone on any
 platform who has made the decision to have helvetica on their machine they
 get an experience which is more consistent across devices, and platforms.


So, the font stack changes with regards to the status quo now change
nothing for Windows users, changes Helvetica - Helvetica neue for Mac
users and changes Arial, DejaVu Sans or Arimo for possibly something else,
amongst which Nimbus Sans L, maybe, maybe not. It's not clear if the linux
change is an improvement, as we have only one test case.

Is that amount of change - effectively changing from Helvetica to Helvetica
neue on Mac and nothing else - really worth defining a non-free font stack
for? Is it even worth the fight over it? Or have we gotten ourselves in a
situation where not backing downhas become more important than the merits
of the discussion. Do you really want to defend the position We must use a
non-free font stack, because otherwise our Mac users will get Helvetica
rather than Helvetica Neue?

--Martijn



 We said from day one that their might be some issues for a few non-latin
 scripts, and we've reached out to the admins of those sites to help them
 make small tweaks, as of jon's patch no one has provided us with any
 screenshots which highlight the issues that have been mentioned from this
 thread, I would welcome those screenshots as well as comments from users
 fluent in the languages to comment on the matter.

 I understand if you don't like it there are a lot of things I don't like
 too. Sadly that is a fact of life. Sometimes we don't like thing, sometimes
 we have to learn to get used to things when they change. The thing that
 confuses me, is that someone would go so far as to try to prohibit others
 from doing their job based on their subjective opinion. Do product and
 design people go and -2 developers patches when they don't agree on the
 choices they've made? They do not. Do you know why? Its because we trust
 them to make good decision based on the acceptance of their knowledge of
 their domain. Why is Design different? Why does everyone think they have
 equal say when it comes to aesthetic choices, its a good question, one I
 don't think I'll try to answer here, but I think the gist of it is that
 everyone has opinions, everyone says I could have done that whether they
 could or not, whether they did or not.

 We try as much as we can, with our limited time, and limited resources to
 validate our decisions in a measurable way. Sometimes this isn't possible,
 sometimes things are immeasurable. Does this mean that we shouldn't do
 them? No, it does not.

 The question was asked, why do we spend so much time on this when there are
 other pressing matters to attend to. The answer is simple, because of this
 process, this discourse where every decision is questioned, because a
 process that should take a month takes six. I honestly want to move on to
 tackle other problems, but if everything that my team or the product teams
 work on comes up for a vote, it questioned to this degree, nothing will
 happen, nothing will improve.

 I'm tired of fighting over this, I'd like to move on, and moving on does
 not mean going on to the status quo.





 *Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

 M : +1 415 609 4043 |   :  @JaredZimmerman
 https://twitter.com/JaredZimmerman



 On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhoris...@gmail.com wrote:

  On 08/04/14 06:57, S Page wrote:
 
  In https://gerrit.wikimedia.org/r/#/c/124475/ (go

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erik Moeller

On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
 So, the font stack changes with regards to the status quo now change
 nothing for Windows users, changes Helvetica - Helvetica neue for Mac
 users and changes Arial, DejaVu Sans or Arimo for possibly something else,
 amongst which Nimbus Sans L, maybe, maybe not.

Actually, it's a bit more complicated. All users get serif fonts for
headings, which they didn't before and which is probably the biggest
visual before/after difference. The serif fonts still prioritize
free/libre fonts over non-free ones.

The body fonts prioritized free/libre fonts on deployments, but for
Windows users without ClearType/anti-aliasing, those render very
poorly, so they were disabled shortly after deployment. This is now
causing people to be upset because the initial agreement to never
prioritize non-free fonts is no longer maintained for the body.

Odder's patch would revert to sans-serif as a generic classification
for the body, but doesn't touch the font specification for the headers
(yet). The commit summary is a bit misleading in that regard.

There's some additional discussion about Georgia as a font choice due
to its use of text figures (AKA old-style numerals), which some people
find look odd in headings with numbers, especially in non-Latin
scripts where old-style numerals may not be commonly encountered. Due
to this, some are arguing for also changing the style for headings to
serif (_not_ sans-serif) as a generic classification, or removing
Georgia from the stack. That particular issue hasn't been discussed in
detail yet, as far as I can see.

I think the differences of opinion here are not worth a holy war.
Prioritizing a non-free font before free ones for the _body_ with a
clear FIXME indicating that this is not a desirable state is IMO only
marginally different from reverting to sans-serif until we have a
free/libre font that _can_ be prioritized for the body. So I think
either outcome should be OK for the short term, and we should focus on
the longer term question of a good font stack for the body that
prioritizes free/libre fonts.

Let's not polarize each other too much. All the arguments I've heard
have been fundamentally reasonable and rational, not just Change is
evil. Some people hate the serifs per se, but that's a smaller
discussion compared to these conversations, which are about
substantial things that can be reasoned about.

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erwin Dokter


On 08-04-2014 19:29, Jared Zimmerman wrote:

I don't really have the energy to keep having this conversation, I
appreciate that everyone has taken the time to weigh in on this whatever
you opinion is on the matter.


I am sorry you feel that way. But I have to make one thing clear:

This is not an aestethic issue. This is a *technical* one.

I do appriciate all the work the designers have done and I do believe 
the new typography is in essense very well thought out.


However, its *technical* implementation is severy flawed.

It has caused many non-latin projects to force them to override the 
global font stack in their local CSS to reset it to sans-serif, because 
parts of their site have become unreadable or illegible. That makes this 
a *breaking change*, and as such, *must* be reverted.


I do not accept that there will be a few readers left with issues; our 
primary goal is legibility. And if legibility is damaged on a world-wide 
encyclopedia, how can you even *think* about defending a breaking change?


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 8:10 AM, Isarra Yos zhoris...@gmail.com wrote:

 Linux often gets arial. Anyone with wine will probably have it installed,
 too, and most will have wine even if they don't use it. It's not
 necessarily a particularly good copy, either.


With the current stack that won't happen even if the user has downloaded
Arial, because Helvetica comes before Arial in the font-family settings.
Linux systems (you can check this using fc-match
https://en.wikipedia.org/wiki/Fontconfig#Utilities) recognize and try to
match Helvetica first. We specifically put Helvetica there first so Linux
users would always get a good free font they have that is equivalent. For
most users (Ubuntu, Debian) this will be Nimbus Sans L.

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

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org wrote:

 On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
 martijnhoeks...@gmail.com wrote:
  So, the font stack changes with regards to the status quo now change
  nothing for Windows users, changes Helvetica - Helvetica neue for Mac
  users and changes Arial, DejaVu Sans or Arimo for possibly something
 else,
  amongst which Nimbus Sans L, maybe, maybe not.

 Actually, it's a bit more complicated. All users get serif fonts for
 headings, which they didn't before and which is probably the biggest
 visual before/after difference. The serif fonts still prioritize
 free/libre fonts over non-free ones.

 The body fonts prioritized free/libre fonts on deployments, but for
 Windows users without ClearType/anti-aliasing, those render very
 poorly, so they were disabled shortly after deployment. This is now
 causing people to be upset because the initial agreement to never
 prioritize non-free fonts is no longer maintained for the body.

 Odder's patch would revert to sans-serif as a generic classification
 for the body, but doesn't touch the font specification for the headers
 (yet). The commit summary is a bit misleading in that regard.


Yes, I should have made that clear: I do very much support the Odder
patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body
to sans serif and keeps @content-heading-font-family: Linux Libertine,
Georgia, Times, serif;

That is not the status quo, but the diff between the Odder patch and the
typography refresh basically is the Set a non-free font stack to give Mac
now Helvetica Neue rather than Helvetica, with a -2 is planted in the
ground before as a demarcation line. That's the point that I don't think is
worth having a non-free font-stack for, and that I certainly think standing
your ground for the brave new world of typography refresh is constructive
for.

[1]My only nitpick about it is that I'm wondering what Times is doing in
that stack. I can't think of any situation where a user wouldn't have Linux
Libertine or Georgia, but does have Times, yet doesn't have it as its
default serif font. When one has specifically set a default serif different
from Times, you probably have a good reason for it - or at least a better
reason than the websites desire for Times, and we should respect that. Yet
this beef is very small compared to all other issues in this thread.



 There's some additional discussion about Georgia as a font choice due
 to its use of text figures (AKA old-style numerals), which some people
 find look odd in headings with numbers, especially in non-Latin
 scripts where old-style numerals may not be commonly encountered. Due
 to this, some are arguing for also changing the style for headings to
 serif (_not_ sans-serif) as a generic classification, or removing
 Georgia from the stack. That particular issue hasn't been discussed in
 detail yet, as far as I can see.

 I think the differences of opinion here are not worth a holy war.
 Prioritizing a non-free font before free ones for the _body_ with a
 clear FIXME indicating that this is not a desirable state is IMO only
 marginally different from reverting to sans-serif until we have a
 free/libre font that _can_ be prioritized for the body. So I think
 either outcome should be OK for the short term, and we should focus on
 the longer term question of a good font stack for the body that
 prioritizes free/libre fonts.

 Let's not polarize each other too much. All the arguments I've heard
 have been fundamentally reasonable and rational, not just Change is
 evil. Some people hate the serifs per se, but that's a smaller
 discussion compared to these conversations, which are about
 substantial things that can be reasoned about.

 Erik
 --
 Erik Möller
 VP of Engineering and Product Development, Wikimedia Foundation

 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Erik Moeller

Just a note that Brandon just commented on the patchset:

We discussed this patch today during our weekly design team meeting
and how to move forward. At this point in time we are leaning towards
+2'ing this but we want to have a bit of discussion internally before
doing so.

We'll have something at the end of the day, so we're asking that no
one merge it until then.

I think that's a completely reasonable request.

Thanks to everyone who's been speaking up in support of positive
changes to our typography while also being constructive and critical
as appropriate. I think one of the cool things about Wikimedia is that
we're willing to try and experiment even at the risk of causing
breakage and disruption, but the flip side of that is listening to
each other and optimizing things together towards the right outcome.
We've got tons of smart people around the world helping with this,
which is awesome. As always, I have confidence in our collective
ability to figure things out :)

Erik
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jon Robson

Copying and pasting what I wrote on that patchset
For the record, I'm happy to +2 this if necessary but I still feel
this is a short term crappy solution that doesn't truly promote unfree
fonts as claimed in the commit message (since we are basically saying
in this give non-free Helvetica for Mac users, Arial for Windows users
[1]) and I'd welcome conversation around finding a suitable open font
to make this more explicit and building a font stack that is language
dependent.

Awaiting agreement... but not pulling the trigger.

[1] http://css-tricks.com/sans-serif/;

I really feel like we are making a mountain out of a mole hill here.
This new patch from Odder doesn't truly achieve supporting open fonts
so in my opinion is no different from the existing state of things
apart from leaving things more up to chance.

On Tue, Apr 8, 2014 at 12:38 PM, Erik Moeller e...@wikimedia.org wrote:
 Just a note that Brandon just commented on the patchset:

 We discussed this patch today during our weekly design team meeting
 and how to move forward. At this point in time we are leaning towards
 +2'ing this but we want to have a bit of discussion internally before
 doing so.

 We'll have something at the end of the day, so we're asking that no
 one merge it until then.

 I think that's a completely reasonable request.

 Thanks to everyone who's been speaking up in support of positive
 changes to our typography while also being constructive and critical
 as appropriate. I think one of the cool things about Wikimedia is that
 we're willing to try and experiment even at the risk of causing
 breakage and disruption, but the flip side of that is listening to
 each other and optimizing things together towards the right outcome.
 We've got tons of smart people around the world helping with this,
 which is awesome. As always, I have confidence in our collective
 ability to figure things out :)

 Erik
 --
 Erik Möller
 VP of Engineering and Product Development, Wikimedia Foundation

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



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

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

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra martijnhoeks...@gmail.com
 wrote:

 On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org wrote:

  On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
  martijnhoeks...@gmail.com wrote:
   So, the font stack changes with regards to the status quo now change
   nothing for Windows users, changes Helvetica - Helvetica neue for Mac
   users and changes Arial, DejaVu Sans or Arimo for possibly something
  else,
   amongst which Nimbus Sans L, maybe, maybe not.
 
  Actually, it's a bit more complicated. All users get serif fonts for
  headings, which they didn't before and which is probably the biggest
  visual before/after difference. The serif fonts still prioritize
  free/libre fonts over non-free ones.
 
  The body fonts prioritized free/libre fonts on deployments, but for
  Windows users without ClearType/anti-aliasing, those render very
  poorly, so they were disabled shortly after deployment. This is now
  causing people to be upset because the initial agreement to never
  prioritize non-free fonts is no longer maintained for the body.
 
  Odder's patch would revert to sans-serif as a generic classification
  for the body, but doesn't touch the font specification for the headers
  (yet). The commit summary is a bit misleading in that regard.
 

 Yes, I should have made that clear: I do very much support the Odder
 patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts body
 to sans serif and keeps @content-heading-font-family: Linux Libertine,
 Georgia, Times, serif;

 That is not the status quo, but the diff between the Odder patch and the
 typography refresh basically is the Set a non-free font stack to give Mac
 now Helvetica Neue rather than Helvetica, with a -2 is planted in the
 ground before as a demarcation line. That's the point that I don't think is
 worth having a non-free font-stack for, and that I certainly think standing
 your ground for the brave new world of typography refresh is constructive
 for.


This is a persistent myth floating around about this. Neue for Mac users is
most definitely not the only effect of explicitly declaring the stack. As
Jared, S Page, and others have already pointed out, and as is stated in the
FAQ on mediawiki.org, the impact of the current stack is:

-- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
or whatever else the default sans is on your distro. Nimbus has an improved
x-height and is much more consistent with the other sans-serifs we're
specifying.
-- Windows users always get Arial, unless they have Helvetica installed.
This means many of the Windows users who might otherwise have set an
alternative sans in their browser default (like Verdana or Tahoma) will now
always get Arial.
-- And yes, Mac users or those with it installed get Neue Helvetica instead
of older version. This is a minor but worthwhile improvement for Mac users.
For example, Neue Helvetica actually has properly designed font weights for
bold, italic, etc. so that the cap height and x-height are consistent
between weights. Regular Helvetica was really not consistently designed
across weights.

Declaring some of the system defaults explicitly is not only an improvement
for Mac users. It means that regardless of whether you switch between
devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
reading long, large blocks of text and is more neutral.



 [1]My only nitpick about it is that I'm wondering what Times is doing in
 that stack. I can't think of any situation where a user wouldn't have Linux
 Libertine or Georgia, but does have Times, yet doesn't have it as its
 default serif font. When one has specifically set a default serif different
 from Times, you probably have a good reason for it - or at least a better
 reason than the websites desire for Times, and we should respect that. Yet
 this beef is very small compared to all other issues in this thread.


Times, like setting Helvetica, is there because it's what Linux systems
recognize and match to. Linux fc-match has no idea what Georgia and Linux
Libertine are unless you've installed them. By setting Times, we ensure
that Linux uses Nimbus Roman No9 L for headings, which complements the body
typeface selected on Linux well and which is consistent in style with the
other serifs specified.

A lot of this stuff is already documented in the FAQ on [[Typography
refresh]] on mediawiki.org. We produced it to answer the basic questions
just like this.




 
  There's some additional discussion about Georgia as a font choice due
  to its use of text figures (AKA old-style numerals), which some people
  find look odd in headings with numbers, especially in non-Latin
  scripts where old-style numerals may not be commonly encountered. Due
  to this, some are arguing for also changing the style for headings to
  serif (_not_ sans-serif) as a generic

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Jared Zimmerman

I want to clarify Steven's point, which was mostly clear but I want to make
sure the details and rationale are pointed out.

When mixing serif and san-serif typefaces using any random two font faces
is not acceptable, therefore letting the browser/OS arbitrarily choose any
serif to pair with any san serif isn't acceptable, if we're following any
rules about pairing typefaces. This is a major argument for keeping font
specifications for both body and header, to keep these harmonious.



*Jared Zimmerman * \\  Director of User Experience \\ Wikimedia Foundation

M : +1 415 609 4043 |   :  @JaredZimmermanhttps://twitter.com/JaredZimmerman



On Tue, Apr 8, 2014 at 1:20 PM, Steven Walling steven.wall...@gmail.comwrote:

 On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra 
 martijnhoeks...@gmail.com
  wrote:

  On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org wrote:
 
   On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
   martijnhoeks...@gmail.com wrote:
So, the font stack changes with regards to the status quo now change
nothing for Windows users, changes Helvetica - Helvetica neue for
 Mac
users and changes Arial, DejaVu Sans or Arimo for possibly something
   else,
amongst which Nimbus Sans L, maybe, maybe not.
  
   Actually, it's a bit more complicated. All users get serif fonts for
   headings, which they didn't before and which is probably the biggest
   visual before/after difference. The serif fonts still prioritize
   free/libre fonts over non-free ones.
  
   The body fonts prioritized free/libre fonts on deployments, but for
   Windows users without ClearType/anti-aliasing, those render very
   poorly, so they were disabled shortly after deployment. This is now
   causing people to be upset because the initial agreement to never
   prioritize non-free fonts is no longer maintained for the body.
  
   Odder's patch would revert to sans-serif as a generic classification
   for the body, but doesn't touch the font specification for the headers
   (yet). The commit summary is a bit misleading in that regard.
  
 
  Yes, I should have made that clear: I do very much support the Odder
  patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
 body
  to sans serif and keeps @content-heading-font-family: Linux Libertine,
  Georgia, Times, serif;
 
  That is not the status quo, but the diff between the Odder patch and the
  typography refresh basically is the Set a non-free font stack to give
 Mac
  now Helvetica Neue rather than Helvetica, with a -2 is planted in the
  ground before as a demarcation line. That's the point that I don't think
 is
  worth having a non-free font-stack for, and that I certainly think
 standing
  your ground for the brave new world of typography refresh is constructive
  for.
 

 This is a persistent myth floating around about this. Neue for Mac users is
 most definitely not the only effect of explicitly declaring the stack. As
 Jared, S Page, and others have already pointed out, and as is stated in the
 FAQ on mediawiki.org, the impact of the current stack is:

 -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
 or whatever else the default sans is on your distro. Nimbus has an improved
 x-height and is much more consistent with the other sans-serifs we're
 specifying.
 -- Windows users always get Arial, unless they have Helvetica installed.
 This means many of the Windows users who might otherwise have set an
 alternative sans in their browser default (like Verdana or Tahoma) will now
 always get Arial.
 -- And yes, Mac users or those with it installed get Neue Helvetica instead
 of older version. This is a minor but worthwhile improvement for Mac users.
 For example, Neue Helvetica actually has properly designed font weights for
 bold, italic, etc. so that the cap height and x-height are consistent
 between weights. Regular Helvetica was really not consistently designed
 across weights.

 Declaring some of the system defaults explicitly is not only an improvement
 for Mac users. It means that regardless of whether you switch between
 devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
 https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
 reading long, large blocks of text and is more neutral.


 
  [1]My only nitpick about it is that I'm wondering what Times is doing in
  that stack. I can't think of any situation where a user wouldn't have
 Linux
  Libertine or Georgia, but does have Times, yet doesn't have it as its
  default serif font. When one has specifically set a default serif
 different
  from Times, you probably have a good reason for it - or at least a better
  reason than the websites desire for Times, and we should respect that.
 Yet
  this beef is very small compared to all other issues in this thread.
 

 Times, like setting Helvetica, is there because it's what Linux systems
 recognize and match to. Linux fc-match has no idea what Georgia and Linux

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling steven.wall...@gmail.comwrote:

 On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra 
 martijnhoeks...@gmail.com
  wrote:

  On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org wrote:
 
   On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
   martijnhoeks...@gmail.com wrote:
So, the font stack changes with regards to the status quo now change
nothing for Windows users, changes Helvetica - Helvetica neue for
 Mac
users and changes Arial, DejaVu Sans or Arimo for possibly something
   else,
amongst which Nimbus Sans L, maybe, maybe not.
  
   Actually, it's a bit more complicated. All users get serif fonts for
   headings, which they didn't before and which is probably the biggest
   visual before/after difference. The serif fonts still prioritize
   free/libre fonts over non-free ones.
  
   The body fonts prioritized free/libre fonts on deployments, but for
   Windows users without ClearType/anti-aliasing, those render very
   poorly, so they were disabled shortly after deployment. This is now
   causing people to be upset because the initial agreement to never
   prioritize non-free fonts is no longer maintained for the body.
  
   Odder's patch would revert to sans-serif as a generic classification
   for the body, but doesn't touch the font specification for the headers
   (yet). The commit summary is a bit misleading in that regard.
  
 
  Yes, I should have made that clear: I do very much support the Odder
  patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
 body
  to sans serif and keeps @content-heading-font-family: Linux Libertine,
  Georgia, Times, serif;
 
  That is not the status quo, but the diff between the Odder patch and the
  typography refresh basically is the Set a non-free font stack to give
 Mac
  now Helvetica Neue rather than Helvetica, with a -2 is planted in the
  ground before as a demarcation line. That's the point that I don't think
 is
  worth having a non-free font-stack for, and that I certainly think
 standing
  your ground for the brave new world of typography refresh is constructive
  for.
 

 This is a persistent myth floating around about this. Neue for Mac users is
 most definitely not the only effect of explicitly declaring the stack. As
 Jared, S Page, and others have already pointed out, and as is stated in the
 FAQ on mediawiki.org, the impact of the current stack is:

 -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation Sans,
 or whatever else the default sans is on your distro. Nimbus has an improved
 x-height and is much more consistent with the other sans-serifs we're
 specifying.


Unfortunately, we didn't properly test this. With the large diversity in
results of the tests we did do on
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt
it's a hard rule that Linux users will now universally get Nimbus Sans L.
I'm also not sure that Nimbus Sans L is the superior alternative over
Liberation Sans. I'm by no means an expert, but in the tests on
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored
exactly the same as Helvetica Neue (both in the good an the bad). Nimbis
Sans L unfortunately hasn't been part of that test.

-- Windows users always get Arial, unless they have Helvetica installed.
 This means many of the Windows users who might otherwise have set an
 alternative sans in their browser default (like Verdana or Tahoma) will now
 always get Arial.


Windows Helvetica seems to be generally a lie, and is not Helvetica but
Helvetica (actually Arial). I don't see overriding a users preference
with our preference as an advantage. Most people don't change their default
font in their browser. In those cases it's probably good if we work with
our preferences instead. If someone put in the effort to set a different
preferred font probably did that for a reason that we shouldn't override. I
assumed that we only wanted to override unset user preferences, and not
actually override the settings that users have explicitly chosen. I was
apparently mistaken in that.

-- And yes, Mac users or those with it installed get Neue Helvetica instead
 of older version. This is a minor but worthwhile improvement for Mac users.
 For example, Neue Helvetica actually has properly designed font weights for
 bold, italic, etc. so that the cap height and x-height are consistent
 between weights. Regular Helvetica was really not consistently designed
 across weights.

 Declaring some of the system defaults explicitly is not only an improvement
 for Mac users. It means that regardless of whether you switch between
 devices/browsers, you always get a grotesque/neo-grotesque sans-serif (
 https://en.wikipedia.org/wiki/Vox-ATypI_classification) which is ideal for
 reading long, large blocks of text and is more neutral.


 
  [1]My only nitpick about it is that I'm wondering what Times is doing in
  that stack. I can't think of any situation

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Matthew Walker

Perhaps this is a question that has an answer elsewhere but, irrespective
of if this change should be made to WMF wikis, why are we:

a) Making this a change in core?

and b) Not making the change in core be a SASS variable that can then be
set as a preference somewhere? (I say this because we've consistently
identified that some languages need different default fonts. If it was a
preference in that we could set via our multiversion scripts it would
obviate the need for overrides in common.css just to make things work.)

~Matt Walker
Wikimedia Foundation
Fundraising Technology Team


On Tue, Apr 8, 2014 at 2:03 PM, Martijn Hoekstra
martijnhoeks...@gmail.comwrote:

 On Tue, Apr 8, 2014 at 10:20 PM, Steven Walling steven.wall...@gmail.com
 wrote:

  On Tue, Apr 8, 2014 at 12:33 PM, Martijn Hoekstra 
  martijnhoeks...@gmail.com
   wrote:
 
   On Tue, Apr 8, 2014 at 8:13 PM, Erik Moeller e...@wikimedia.org
 wrote:
  
On Tue, Apr 8, 2014 at 10:59 AM, Martijn Hoekstra
martijnhoeks...@gmail.com wrote:
 So, the font stack changes with regards to the status quo now
 change
 nothing for Windows users, changes Helvetica - Helvetica neue for
  Mac
 users and changes Arial, DejaVu Sans or Arimo for possibly
 something
else,
 amongst which Nimbus Sans L, maybe, maybe not.
   
Actually, it's a bit more complicated. All users get serif fonts for
headings, which they didn't before and which is probably the biggest
visual before/after difference. The serif fonts still prioritize
free/libre fonts over non-free ones.
   
The body fonts prioritized free/libre fonts on deployments, but for
Windows users without ClearType/anti-aliasing, those render very
poorly, so they were disabled shortly after deployment. This is now
causing people to be upset because the initial agreement to never
prioritize non-free fonts is no longer maintained for the body.
   
Odder's patch would revert to sans-serif as a generic classification
for the body, but doesn't touch the font specification for the
 headers
(yet). The commit summary is a bit misleading in that regard.
   
  
   Yes, I should have made that clear: I do very much support the Odder
   patch[1] ( https://gerrit.wikimedia.org/r/#/c/124475/ ) that reverts
  body
   to sans serif and keeps @content-heading-font-family: Linux
 Libertine,
   Georgia, Times, serif;
  
   That is not the status quo, but the diff between the Odder patch and
 the
   typography refresh basically is the Set a non-free font stack to give
  Mac
   now Helvetica Neue rather than Helvetica, with a -2 is planted in the
   ground before as a demarcation line. That's the point that I don't
 think
  is
   worth having a non-free font-stack for, and that I certainly think
  standing
   your ground for the brave new world of typography refresh is
 constructive
   for.
  
 
  This is a persistent myth floating around about this. Neue for Mac users
 is
  most definitely not the only effect of explicitly declaring the stack. As
  Jared, S Page, and others have already pointed out, and as is stated in
 the
  FAQ on mediawiki.org, the impact of the current stack is:
 
  -- Linux users get Nimbus Sans L, instead of DejaVu Sans, Liberation
 Sans,
  or whatever else the default sans is on your distro. Nimbus has an
 improved
  x-height and is much more consistent with the other sans-serifs we're
  specifying.
 

 Unfortunately, we didn't properly test this. With the large diversity in
 results of the tests we did do on
 https://www.mediawiki.org/wiki/Typography_refresh/Font_choice/Test I doubt
 it's a hard rule that Linux users will now universally get Nimbus Sans L.
 I'm also not sure that Nimbus Sans L is the superior alternative over
 Liberation Sans. I'm by no means an expert, but in the tests on
 https://www.mediawiki.org/wiki/Typography_refresh/Font_choice it scored
 exactly the same as Helvetica Neue (both in the good an the bad). Nimbis
 Sans L unfortunately hasn't been part of that test.

 -- Windows users always get Arial, unless they have Helvetica installed.
  This means many of the Windows users who might otherwise have set an
  alternative sans in their browser default (like Verdana or Tahoma) will
 now
  always get Arial.
 

 Windows Helvetica seems to be generally a lie, and is not Helvetica but
 Helvetica (actually Arial). I don't see overriding a users preference
 with our preference as an advantage. Most people don't change their default
 font in their browser. In those cases it's probably good if we work with
 our preferences instead. If someone put in the effort to set a different
 preferred font probably did that for a reason that we shouldn't override. I
 assumed that we only wanted to override unset user preferences, and not
 actually override the settings that users have explicitly chosen. I was
 apparently mistaken in that.

 -- And yes, Mac users or those with it installed get Neue Helvetica instead
  of older version. This

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Daniel Friesen

On 2014-04-08, 12:33 PM, Martijn Hoekstra wrote:
 That is not the status quo, but the diff between the Odder patch and the
 typography refresh basically is the Set a non-free font stack to give Mac
 now Helvetica Neue rather than Helvetica, with a -2 is planted in the
 ground before as a demarcation line. That's the point that I don't think is
 worth having a non-free font-stack for, and that I certainly think standing
 your ground for the brave new world of typography refresh is constructive
 for.
Just to randomly chime in here, as someone using a Mac bought for my
personal use by my employer awhile ago in my daily activities, I'd
prefer that the difference between Helvetica and Helvetica Neue is not
belittled.

Helvetica is an ancient font, created for print in 1957. Helvetica Neue
was still only created in 1983 but its goal of being an improvement over
Helvetica still carries over to the current computer fonts nonetheless.
I can't fathom why Helvetica is still in use when a variant created
specifically to be more legible than base Helvetica is now available –
some would say any variant of Helvetica doesn't belong on the web[1],
but Neue is still an improvement.

Flipping between Helvetica and Helvetica Neue by turning on and off a
font-face: sans-serif; overriding the current `Helvetica Neue,
Helvetica, Arial, sans-serif` on en.wp's main page I can see a notable
difference between the two.

Primarily in the kerning, Helvetica Neue's kerning is much better than
Helvetica's, which simultaneously leaves extra space between letters
when not needed and uses too little space between letters when it's
necessary for legibility.

In general Neue has better kerning between letters, putting things
closer together:
- In Main Page it drops the unnecessary space inside Pa that Helvetica
has.
- In Main page in the sidebar it puts all letters closer together,
dropping unnecessary space between ai and ag
- In the content All drops unnecessary space between ll and The
drops unnecessary space between Th
- and so on

While in other cases Neue separates things that Helvetica puts together
to it's detriment: cl, co, ct, te, all have extra space between them,
while Helvetica puts them close together in ways that could be mistaken
for other letters (d, oo, d, b).

[1] http://www.64notes.com/design/stop-helvetica-arial/

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] Free fonts and Windows users

On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker mwal...@wikimedia.orgwrote:

 Perhaps this is a question that has an answer elsewhere but, irrespective
 of if this change should be made to WMF wikis, why are we:

 a) Making this a change in core?

 and b) Not making the change in core be a SASS variable that can then be
 set as a preference somewhere? (I say this because we've consistently
 identified that some languages need different default fonts. If it was a
 preference in that we could set via our multiversion scripts it would
 obviate the need for overrides in common.css just to make things work.)


The patches (such as the first one at
https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that
define Vector styles. So they're in core because Vector is in core. Based
on conversations with Jon we should be able to work out how to do per-wiki
or preferably per-language styles, right?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Matthew Walker

On Tue, Apr 8, 2014 at 6:46 PM, Steven Walling steven.wall...@gmail.comwrote:

 On Tue, Apr 8, 2014 at 2:18 PM, Matthew Walker mwal...@wikimedia.org
 wrote:

  Perhaps this is a question that has an answer elsewhere but, irrespective
  of if this change should be made to WMF wikis, why are we:
 
  a) Making this a change in core?
 
  and b) Not making the change in core be a SASS variable that can then be
  set as a preference somewhere? (I say this because we've consistently
  identified that some languages need different default fonts. If it was a
  preference in that we could set via our multiversion scripts it would
  obviate the need for overrides in common.css just to make things work.)
 

 The patches (such as the first one at
 https://gerrit.wikimedia.org/r/#/c/120978/) are to the LESS variables that
 define Vector styles.


Fair enough.


 So they're in core because Vector is in core. Based
 on conversations with Jon we should be able to work out how to do per-wiki
 or preferably per-language styles, right?


Ideally yes; not sure if we have support for that yet or not. I'll defer to
Jon. :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

On Mon, Apr 7, 2014 at 1:19 PM, Jon Robson jrob...@wikimedia.org wrote:

 1) Picking a new open font that is either
 ** widely available on Linux but not so much on Windows
 ** renders well in Windows


Coming back to the above option...

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

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

[I am copying the above to the Talk page on mediawiki.org in case anyone
else is interested.]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-08 Thread Risker

I've been sitting back watching this thread as it has unfolded, as well as
the discussions in a few other places, to better understand how this
particular subset of the Wikimedia/Mediawiki community problem-solved.  I'd
like to share with you all a few observations.

Steven and Jon, consider having coffee with your colleague Siko Bouterse.
Siko can tell you all about how to fail successfully.  Yes, I know it's an
oxymoron, but there are huge opportunities in trying something, having it
fail, and deriving goodwill, experience and knowledge from that failure.
You've got an amazing opportunity here to learn from a well-intentioned
process that has had significant unanticipated negative effects.  As best I
can tell, nobody doubts that this project was undertaken in good faith, and
nobody doubts that you and your team are disappointed that its outcome is
not what was anticipated.

There is a bit of amnesia about the fact that almost all editors are also
readers and regular users of the projects we create, and those editors have
been encouraged since Day One to inform developers of any technical
problems with the site; they're the canaries in the coal mine.  And for
anyone who's been editing more than 3-4 years (an ever-increasing
percentage of the editing community), software issues were things they
had to pretty much solve themselves within the volunteer community. For
years, most developers were volunteers too, and had close links to the
editing community.  At least a good portion of you remember those days -
because you used to be those volunteer developers that community members
would hit up to fix things, and you used to watch the village pumps to
figure out what else needed to be fixed. Until very recently, it was almost
unheard-of for community members to be told that problematic things were
going to stay that way because of a decision made by a small number of
people in an office somewhere.  When most developers were clearly
participating as community members, they behaved as though they were, at
least to a significant extent, accountable to both the editing and
Mediawiki communities; I'm not sure that sense of accountability exists
anymore.  Now, I don't think anyone begrudges the many talented developers
who started off within the community having taken the opportunity to move
on to paid positions at the WMF, and I think on the whole the big-picture
community is overall very happy with the majority of changes that have come
with the increased professionalization of the site engineering and
operations.  But this is a major change in culture, and the gulf between
volunteers (either developer or editor) and WMF staff is widening
noticeably as time progresses.  I could tell who was a volunteer and who
was staff from the way their posts were responded to in this thread; I
doubt that would have been the case even two years ago.

It's pretty clear that the objectives of this project are not successfully
met at this point, and in fact have caused major problems on non-Latin
script WMF sites, and significant but less critical problems on Latin
script sites. Several factors for this have been identified in the thread -
including limited attention to the effects on non-Latin script projects,
the insertion of philosophical principles (FOSS) without a clear
understanding of the effects this would have on the outcome, and the
unwillingness to step back when a major change results in loss of
functionality.

Think a bit more.  If this change is a cornerstone of future design
changes, it needs to work on all WMF projects, and as currently structured
you already know it can't.  It may well be best to pull back to status quo
ante in order to consider how to design not just for Latin-script sites,
but for Chinese, Arabic and Vietnamese ones.  Members of those communities
may not be writing to this mailing list, but most of the non-Latin projects
are growing much faster than the older, Latin-script sites.  They're our
future.  They have to be in the mix.

Best,

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Isarra Yos


On 07/04/14 20:19, Jon Robson wrote:

After the deploy last Thursday various users on Village Pumps bug
reports and external sites (e.g. Twitter and Reddit) were informing us
that the new typography was unreadable. Sadly it was difficult to
distinguish whether this was simply a dislike of the new fonts or
something deeper related to a bug.

After lots of experimentation and reaching out to users on Friday, we
discovered that the free fonts in the stack were rendering very poorly
on some Windows machines. I experimented with some live hacks to beta
labs to try and identify the problems [1] with a user who was
experiencing the problem. I tested various things like
text-size-adjust and font size. The problem that caused the text to be
unreadable for the user was the Liberation Sans font [2]

I tried to restore Arimo [3] and although it was fine for this
particular user, it wasn't fine for another user, meaning both our
fonts were causing issues. As a result, I have pulled together a small
patch to remove these fonts [4]. This is meant as only a short term
solution.

As for a long term solution, what can we do? Ideas in my head involve
1) Picking a new open font that is either
** widely available on Linux but not so much on Windows
** renders well in Windows
2) We create our own open font, maybe forking an existing font.
3) We restore these two fonts to the font stack but using JavaScript
either enable or disable them on Windows machines
4) We identify the issues here with the existing fonts, filing
upstream bugs and find a timeframe in which we can restore them by
5) Insert your idea here

I welcome your ideas on how we can find an open font that keeps all users happy.

Is it worth opening an RFC on MediaWiki.org to discuss our options some more?

[1] 
http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Common.cssaction=history
[2] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501
[3] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501...86502
[4] https://gerrit.wikimedia.org/r/124387


5) Restore the status quo - specifying 'sans-serif' as the font, which 
translates to the default font for the platform, had none of these 
problems, and resulted in fonts for all platforms which were good for 
those platforms (though perhaps not necessarily the best).


 * Windows users got fonts optimised for Windows, and which Windows
   knows well how to render. They may not be free, but /we/ weren't the
   ones prioritising the non-free.
 * Linux users got whatever (probably free) font their distribution
   provides, for which in all likelihood their fontconfig (rendering
   settings) is also optimised.
 * Those with cleartype etc off previously had fonts that rendered
   properly or they would not have been using their system with
   cleartype etc off for all this time.
 * Anyone previously using free fonts, on whatever platform, did not
   have their choices overridden. This also applies to those using
   dyslexic-friendly and other accessibility-oriented fonts.
 * And so on.


Given that no objective and verifiable issues with this were ever 
provided to explain the need for a shift to specific fonts across all 
platforms and languages in the first place, this means there should also 
be no issues with going back.


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Bjoern Hoehrmann

* Isarra Yos wrote:
5) Restore the status quo - specifying 'sans-serif' as the font, which 
translates to the default font for the platform, had none of these 
problems, and resulted in fonts for all platforms which were good for 
those platforms (though perhaps not necessarily the best).

  * Windows users got fonts optimised for Windows, and which Windows
knows well how to render. They may not be free, but /we/ weren't the
ones prioritising the non-free.
  * Linux users got whatever (probably free) font their distribution
provides, for which in all likelihood their fontconfig (rendering
settings) is also optimised.
  * Those with cleartype etc off previously had fonts that rendered
properly or they would not have been using their system with
cleartype etc off for all this time.
  * Anyone previously using free fonts, on whatever platform, did not
have their choices overridden. This also applies to those using
dyslexic-friendly and other accessibility-oriented fonts.
  * And so on.


Given that no objective and verifiable issues with this were ever 
provided to explain the need for a shift to specific fonts across all 
platforms and languages in the first place, this means there should also 
be no issues with going back.

Sounds very good to me.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

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

Re: [Wikitech-l] Free fonts and Windows users

This. Let's go back to what we *know* worked.

-Chad
On Apr 7, 2014 1:52 PM, Isarra Yos zhoris...@gmail.com wrote:

 On 07/04/14 20:19, Jon Robson wrote:

 After the deploy last Thursday various users on Village Pumps bug
 reports and external sites (e.g. Twitter and Reddit) were informing us
 that the new typography was unreadable. Sadly it was difficult to
 distinguish whether this was simply a dislike of the new fonts or
 something deeper related to a bug.

 After lots of experimentation and reaching out to users on Friday, we
 discovered that the free fonts in the stack were rendering very poorly
 on some Windows machines. I experimented with some live hacks to beta
 labs to try and identify the problems [1] with a user who was
 experiencing the problem. I tested various things like
 text-size-adjust and font size. The problem that caused the text to be
 unreadable for the user was the Liberation Sans font [2]

 I tried to restore Arimo [3] and although it was fine for this
 particular user, it wasn't fine for another user, meaning both our
 fonts were causing issues. As a result, I have pulled together a small
 patch to remove these fonts [4]. This is meant as only a short term
 solution.

 As for a long term solution, what can we do? Ideas in my head involve
 1) Picking a new open font that is either
 ** widely available on Linux but not so much on Windows
 ** renders well in Windows
 2) We create our own open font, maybe forking an existing font.
 3) We restore these two fonts to the font stack but using JavaScript
 either enable or disable them on Windows machines
 4) We identify the issues here with the existing fonts, filing
 upstream bugs and find a timeframe in which we can restore them by
 5) Insert your idea here

 I welcome your ideas on how we can find an open font that keeps all users
 happy.

 Is it worth opening an RFC on MediaWiki.org to discuss our options some
 more?

 [1] http://en.wikipedia.beta.wmflabs.org/w/index.php?title=
 MediaWiki:Common.cssaction=history
 [2] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:MobileDiff/86501
 [3] http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:
 MobileDiff/86501...86502
 [4] https://gerrit.wikimedia.org/r/124387


 5) Restore the status quo - specifying 'sans-serif' as the font, which
 translates to the default font for the platform, had none of these
 problems, and resulted in fonts for all platforms which were good for those
 platforms (though perhaps not necessarily the best).

  * Windows users got fonts optimised for Windows, and which Windows
knows well how to render. They may not be free, but /we/ weren't the
ones prioritising the non-free.
  * Linux users got whatever (probably free) font their distribution
provides, for which in all likelihood their fontconfig (rendering
settings) is also optimised.
  * Those with cleartype etc off previously had fonts that rendered
properly or they would not have been using their system with
cleartype etc off for all this time.
  * Anyone previously using free fonts, on whatever platform, did not
have their choices overridden. This also applies to those using
dyslexic-friendly and other accessibility-oriented fonts.
  * And so on.


 Given that no objective and verifiable issues with this were ever provided
 to explain the need for a shift to specific fonts across all platforms and
 languages in the first place, this means there should also be no issues
 with going back.

 -I
 ___
 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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Isarra Yos


On 07/04/14 21:03, Martijn Hoekstra wrote:

+1, but to me 'serif' rather than 'sans-serif' for the section headers is
nicer. YMMV and can certainly live with sans for section headers

Having different serif for the headers with sans-serif content can be a 
bit dangerous, depending on the fonts in question (or just plain in 
general, depending on the language - not all even have concepts of serif 
and sans-serif, or treat them the same way). If a platform has serif and 
sans-serif fonts that were specifically designed to work together (with 
consistent dimensions, weight, etc), indeed, it can work quite well. 
There's just no guarantee that this will be the case on all unless you 
use webfonts (gw2 does this to good effect, for instance), as even the 
default fonts may not be from the same sets.


-I

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Erwin Dokter


On 07-04-2014 22:52, Isarra Yos wrote:


5) Restore the status quo - specifying 'sans-serif' as the font


+1 for option 5. I have posted my preliminary evaluation at [1] and [2], 
which basically deals with why this update is so Latin-centric, and has 
non-latin scripts users left with a totally useless font stack.


[1] https://www.mediawiki.org/wiki/Talk:Typography refresh#Evaluation
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=63512#c20

Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Tomasz W . Kozlowski

Chad writes:
 
 This. Let's go back to what we *know* worked.

https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so you're 
/just/ late – unless you want to submit yet another patch reverting to sans-
serif.

Tomasz




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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Steven Walling

On Mon, Apr 7, 2014 at 1:52 PM, Isarra Yos zhoris...@gmail.com wrote:

 5) Restore the status quo - specifying 'sans-serif' as the font, which
 translates to the default font for the platform, had none of these
 problems, and resulted in fonts for all platforms which were good for those
 platforms (though perhaps not necessarily the best).


We're not going to do this.

 The idea that one bug requires a complete revert and even more disruption
for users is pretty absurd. Do we revert deployment of an extension every
time a bug occurs? No. We do it when the disruption caused by keeping the
new version is greater than taking it away again. This is not one of those
times.

We made the last change, which includes vital improvements besides slightly
altered body copy font family, after months of testing and prep. But all
new software has bugs, even simple LESS-only changes when they have a
scope this wide. The latest patch by Jon was a bug fix, but that doesn't
mean we're going to cause further disruption for users by completely
reverting back to the old defaults.

What we're going to do is discuss the options Jon laid out for trying to
promote free fonts in our stack, while also being practical and retaining
the enhancements that most users have been delivered so far. This is why we
iterate on changes in any realm of design and development.

I'll also nudge us here to remember that we cannot make design decisions
like this in a vacuum, without feedback from non-technical users. It wasn't
perfect, but we've been working hard to do that as part of Typography
Refresh. Jon's latest bug fix itself is based on reports from many users.
So far they've been thankful we did this.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Jon Robson

I noticed from Kaldari's notes [1] that Open sans was rejected based
on language support and install base. I notice however that it is
pretty popular on the web [2,3]. Can someone elaborate on these
results as it is surprised me?

To me we can learn from this experience that install base (especially
where Windows is concerned) is probably not such an important factor.
The language support is more of an issue, but I wonder if this can be
resolved by specific font stacks with more suitable open fonts is
provided.

To improve install base we can easily iterate on this and start using
web fonts in some form in the future.

[1] 
https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
[2] http://www.typeandgrids.com/blog/the-ten-most-popular-web-fonts-of-2013
[3] 
http://www.smashingmagazine.com/2014/03/12/taking-a-second-look-at-free-fonts/

On Mon, Apr 7, 2014 at 2:49 PM, Tomasz W. Kozlowski
tom...@twkozlowski.net wrote:
 Chad writes:

 This. Let's go back to what we *know* worked.

 https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so you're
 /just/ late - unless you want to submit yet another patch reverting to sans-
 serif.

 Tomasz




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



-- 
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Steven Walling

On Mon, Apr 7, 2014 at 3:42 PM, Jon Robson jdlrob...@gmail.com wrote:

 I noticed from Kaldari's notes [1] that Open sans was rejected based
 on language support and install base. I notice however that it is
 pretty popular on the web [2,3]. Can someone elaborate on these
 results as it is surprised me?

 To me we can learn from this experience that install base (especially
 where Windows is concerned) is probably not such an important factor.
 The language support is more of an issue, but I wonder if this can be
 resolved by specific font stacks with more suitable open fonts is
 provided.

 To improve install base we can easily iterate on this and start using
 web fonts in some form in the future.

 [1]
 https://www.mediawiki.org/wiki/Typography_refresh/Font_choice#Body_font_evaluation
 [2]
 http://www.typeandgrids.com/blog/the-ten-most-popular-web-fonts-of-2013
 [3]
 http://www.smashingmagazine.com/2014/03/12/taking-a-second-look-at-free-fonts/


A similar example is Google's Noto font (
https://en.wikipedia.org/wiki/Noto_fonts). It has basically no default
install base that I'm aware of, but it's focused on readability in as many
scripts as possible and is Apache-licensed.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Greg Grossmeier

Private/offlist

Steven,

I think you're missing what Issara and others like myself have
suggested: just reverting the fontstack part, not the
font-size/color/etc that are a part of the changeset.

Greg

quote name=Steven Walling date=2014-04-07 time=15:41:02 -0700
 On Mon, Apr 7, 2014 at 1:52 PM, Isarra Yos zhoris...@gmail.com wrote:
 
  5) Restore the status quo - specifying 'sans-serif' as the font, which
  translates to the default font for the platform, had none of these
  problems, and resulted in fonts for all platforms which were good for those
  platforms (though perhaps not necessarily the best).
 
 
 We're not going to do this.
 
  The idea that one bug requires a complete revert and even more disruption
 for users is pretty absurd. Do we revert deployment of an extension every
 time a bug occurs? No. We do it when the disruption caused by keeping the
 new version is greater than taking it away again. This is not one of those
 times.
 
 We made the last change, which includes vital improvements besides slightly
 altered body copy font family, after months of testing and prep. But all
 new software has bugs, even simple LESS-only changes when they have a
 scope this wide. The latest patch by Jon was a bug fix, but that doesn't
 mean we're going to cause further disruption for users by completely
 reverting back to the old defaults.
 
 What we're going to do is discuss the options Jon laid out for trying to
 promote free fonts in our stack, while also being practical and retaining
 the enhancements that most users have been delivered so far. This is why we
 iterate on changes in any realm of design and development.
 
 I'll also nudge us here to remember that we cannot make design decisions
 like this in a vacuum, without feedback from non-technical users. It wasn't
 perfect, but we've been working hard to do that as part of Typography
 Refresh. Jon's latest bug fix itself is based on reports from many users.
 So far they've been thankful we did this.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Greg Grossmeier

quote name=Greg Grossmeier date=2014-04-07 time=15:57:39 -0700
 Private/offlist

well crap.

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Free fonts and Windows users

 Sadly it was difficult to
 distinguish whether this was simply a dislike of the new fonts or
 something deeper related to a bug.

Since, you're changing something primarily for aesthetic purposes (I think
anyways, all the accounts of why we even would want to change the font are
very hand wavey and I'm honestly unsure what the principle motivations
actually are), why isn't dislike of the new font a valid criticism? After
all, the reason you are changing it in the first place is that you
presumably did not like the old font.

 5) Insert your idea here


Browsing through the feedback on this thing, there seems to an enormus
amount of hate in our userbase for it. Lots of that is of the form of its
ugly which some might argue is not constructive, but I personally think is
something that should be taken into consideration when there are so many
people making the complaint, and the change is mostly about aesthetics.
Others have more concrete criticisms about eye strain and non latin text
not working as good, etc.

Anyways to sum it up, this change is:
*Fixing something that most users think is not a problem [citation needed,
but that is my impression]
*Causing behavior that significant numbers of users do not like (e.g.
IDONTLIKEIT, its ugly, etc). A subset of users are experiancing behaviour
that is objectively bad
*In order to make it work acceptably, has to do something that a portion of
our community finds ideaologically questionable, if not outright
unacceptable. (Remember folks, we are a project built on ideaology.
Ideaology is important)

Given the above, it seems like a temporary revert until solutions to the
problems can be found, or a permenant revert if solutions can't be found,
may be advisible.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Erwin Dokter


On 08-04-2014 00:45, Steven Walling wrote:

On Mon, Apr 7, 2014 at 3:42 PM, Jon Robson jdlrob...@gmail.com wrote:


I noticed from Kaldari's notes [1] that Open sans was rejected based
on language support and install base.



A similar example is Google's Noto font (
https://en.wikipedia.org/wiki/Noto_fonts). It has basically no default
install base that I'm aware of, but it's focused on readability in as many
scripts as possible and is Apache-licensed.


Noto is useless without a suitable localization mechanism.

I feel that I am not being taken seriously. Three times now I have 
indicated what is wrong with this solution, namely that a single font 
stack cannot possibly serve a global website.


I want to ask Steven and Jon how they plan on serving *all* the scripts 
and languages in the world in a *single* font stack. There is not a 
single font in existence that can possibly support all languages.


Again, this excercise is completely Latin-centered. Projects using 
different script have no choice but to override to their native fonts, 
and only Europe/Americas is left to 'enjoy' the new font stack.


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

On Mon, Apr 7, 2014 at 2:49 PM, Tomasz W. Kozlowski
tom...@twkozlowski.netwrote:

 Chad writes:

  This. Let's go back to what we *know* worked.

 https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so
 you're
 /just/ late – unless you want to submit yet another patch reverting to
 sans-
 serif.


I would write said patch but I have no desire to get into WWIII on
Gerrit over it. I've already fixed the whole nasty mess anyway and
put MW back to how it should be[0]

-Chad

[0] https://en.wikipedia.org/wiki/User:%5edemon/common.css
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Jon Robson

 I feel that I am not being taken seriously. Three times now I have indicated
 what is wrong with this solution, namely that a single font stack cannot
 possibly serve a global website.

I'm sorry you feel this way, if I wasn't clear, I agree with you, but
I think where we disagree is that we could support multiple font
stacks based on language.

 I want to ask Steven and Jon how they plan on serving *all* the scripts and
 languages in the world in a *single* font stack. There is not a single font
 in existence that can possibly support all languages.
Yes I thought I had recognised this. See my message above:  The
language support is more of an issue, but I wonder if this can be
resolved by specific font stacks with more suitable open fonts is
provided.
I think we have a great chance to iterate from here and get better
font stacks for all our languages. LESS supports configurable
variables after all.

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Erwin Dokter


On 08-04-2014 01:14, Jon Robson wrote:

Yes I thought I had recognised this. See my message above:  The
language support is more of an issue, but I wonder if this can be
resolved by specific font stacks with more suitable open fonts is
provided.
I think we have a great chance to iterate from here and get better
font stacks for all our languages. LESS supports configurable
variables after all.


Ah OK. Wouldn't it be better then to implement this when MediaWiki has 
sufficient support to discriminate requested languages and serve the 
appropriate fontstack accordingly?


Also, most free fonts are Latin-only, and only a few (like Noto) aim for 
global support. And all free fonts will have issues on Windows (with 
font-smooting disabled). My priority is stil to go with What-Works-Best 
for all, and less with Must-Include-Free-Font.


Regards,
--
Erwin Dokter


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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread MZMcBride

Hi.

I've read through this thread and I've formulated two questions:

* Is there consensus to specify font-family: 'Helvetica Neue', Helvetica,
Arial, sans-serif; in MediaWiki core?

* Is there an issue with specifying font-family: sans-serif; in
MediaWiki core?

Based on my reading of this thread, associated bug reports, and talk
pages, the answer to both of these questions seems to be pretty clearly
no.

There's no consensus currently to specify a non-free font stack and
several people on this mailing list (Isarra, bawolff, Chad, Greg G.,
Bjoern, Martijn, et al.) have now suggested going back to sans-serif.

Steven and Jon: I would appreciate if the two of you could address these
two questions directly. Is there consensus for the changes you two have
made? And is there an issue with simply specifying sans-serif?

The consistency rationale seems very feeble as Web browsers, operating
systems, etc. vary widely and no font stack can adequately address that.

Steven specifically has suggested that changing the default back to
sans-serif would be disruptive, but I can't fathom what would be
disruptive about that. Actively damaging the user experience with these
changes _is_ disruptive. Going back to the status quo... not so much.

MZMcBride



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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Isarra Yos

On 08/04/14 00:02, Steven Walling wrote:

On Mon, Apr 7, 2014 at 4:08 PM, Erwin Dokter er...@darcoury.nl wrote:

I feel that I am not being taken seriously. Three times now I have
indicated what is wrong with this solution, namely that a single font stack
cannot possibly serve a global website.

I want to ask Steven and Jon how they plan on serving *all* the scripts
and languages in the world in a *single* font stack. There is not a single
font in existence that can possibly support all languages.

I think we actually answered this up front at
https://www.mediawiki.org/wiki/Typography_refresh#Is_there_a_perfect_font_that_meets_our_readability_needs_in_all_scripts.3F_Do_we_think_this_is_it.3F

Ultimately we're shooting for and getting a lot more consistency and
control over the user experience here, for most users. That doesn't meant
that it's perfect. There is definitely not a single font that is available
everywhere that supports all languages. That's why it's a font stack with
fallbacks. We definitely don't gain more consistency across the experience
by moving back to a situation where the styles basically just define no
style.

Again, this excercise is completely Latin-centered. Projects using
different script have no choice but to override to their native fonts, and
only Europe/Americas is left to 'enjoy' the new font stack.

To add on to what Jon said: we're going to figure this out in discussion
with the communities. I don't think it's the case at all that users have
no choice if they want readable text in a non-Latin script. To use CJK as
an example: I actually was able to remove some local hacks that were
necessary before the new version. We'll keep working on it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Why? All this effort, and for what? You want consistency in what's given
to the users, but users are not consistent. Their hardware is not
consistent, nor are their operating systems, languages, eyes, brains,
habits, or preferences. As was, the default sans-serif already addressed
these inconsistencies, giving them something that worked for them. Why
go to all this trouble when the problem was already solved? What's the
point?

-I

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

Re: [Wikitech-l] Free fonts and Windows users

On 4/7/14, Steven Walling steven.wall...@gmail.com wrote:
On Mon, Apr 7, 2014 at 4:08 PM, Erwin Dokter er...@darcoury.nl wrote:

I feel that I am not being taken seriously. Three times now I have
indicated what is wrong with this solution, namely that a single font
stack
cannot possibly serve a global website.

I think we actually answered this up front at
https://www.mediawiki.org/wiki/Typography_refresh#Is_there_a_perfect_font_that_meets_our_readability_needs_in_all_scripts.3F_Do_we_think_this_is_it.3F

No you don't get more consistency by moving back to an experience
where you let the browser determine fonts. However you do get a
situation where things are more likely to work for non-latin scripts
(and other issues that have been brought up, if I understand
correctly). Consistency and actually working for all scripts are
separate goals. If you can't satisfy both, you're going to have to
make one take higher priority than the other. I personally consider
the Actually working for all languages to be much more important
consideration than consistency.

Which is not to say its impossible to satisfy both. Maybe it is, maybe
it isn't (Not really my area of knowledge). But from what I hear,
currently we are not satisfying both.

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Steven Walling

On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff bawo...@gmail.com wrote:

 No you don't get more consistency by moving back to an experience
 where you let the browser determine fonts. However you do get a
 situation where things are more likely to work for non-latin scripts
 (and other issues that have been brought up, if I understand
 correctly). Consistency and actually working for all scripts are
 separate goals. If you can't satisfy both, you're going to have to
 make one take higher priority than the other. I personally consider
 the Actually working for all languages to be much more important
 consideration than consistency.


I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif
headings, since serifs look closer to a brush script in those languages
than they do in Latin languages. That doesn't seem to be what we're
discussing though? When it comes to the body font settings and language
support, we've been able to remove some local overrides. Some others, like
Persian, had Common.css overrides long before the new version was released.
The general state of affairs before *and* after is that there aren't
great-looking, freely-licensed fonts with support across all languages and
which are widely installed on our most popular OS/device combos. We're
making incremental improvements here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Free fonts and Windows users

2014-04-07 Thread Tim Landscheidt

(anonymous) wrote:

  This. Let's go back to what we *know* worked.

 https://gerrit.wikimedia.org/r/#/c/124387/ has already been merged, so
 you're
 /just/ late – unless you want to submit yet another patch reverting to
 sans-
 serif.

 I would write said patch but I have no desire to get into WWIII on
 Gerrit over it. I've already fixed the whole nasty mess anyway and
 put MW back to how it should be[0]

 [0] https://en.wikipedia.org/wiki/User:%5edemon/common.css

So we just need to get https://bugzilla.wikimedia.org/57891
(Review and deploy GlobalCssJs extension to Wikimedia
wikis) fixed :-).

Tim


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

Re: [Wikitech-l] Free fonts and Windows users


 I am going to be annoying and answer your question with a question:
 consensus among who? How do make a decision like this?

 On the one hand, you have Wikimedia users, who don't really care about the
 appearance of promoting FOSS or not.

[Citation needed]. User's aren't one person, but quite a varied group.
However I believe a lot of them care about promoting FOSS. Just look
at the MP4 RFC. Obviously not all Wikimedia users voted in that
(especially if you're including non-editors in the user category), but
a significant chunk did.

After all, we are talking about a project, where people, out of the
goodness of the heart spend their time writing high quality
educational articles without compensation. I would imagine that a good
portion (not all) of the types of people attracted to doing this are
also the type of people who would be attracted to the ideals of the
FOSS movements.

 They just want to things to work and
 look good.

Well yes. Don't we all?

 They also believe that the only consensus that matters is the
 one on their local wiki.

To be fair, they don't really have an opportunity to participate in a
larger consensus.



 On the other hand, we have MediaWiki developers, some of whom would rather
 throw up their hands and not specify a real font stack,

Well that's an antagonistic way of phrasing it.

By the same count, MediaWiki developers would rather throw up their
hands then make #expr accept localized numbers (bug 30318), or any
other of the thousands of WONTFIXed bugs.

 rather than touch
 the non-free fonts *most users already have* with a ten foot pole.

Whether or not the non-free fonts are installed on the users system
seems irrelavent to the concerns that the non-free font crowd have
raised.

There's a big difference between saying Do whatever you think is
best compared to Do X if possible, even if both statements evaluate
to doing the same action.

 They
 seem to think that an RFC or discussion on Wikitech-l is what represents a
 consensus that must be respected.

I'm not sure if people actually think that (or if they do think that,
that they actually said that). One person (MZMcBride) implied that
kind of heavily, most of the other revert-ish threads are not using
the because concensus (or lack thereof) on wikitech-l as an
argument.

There is a historical precedent for development decisions being made
not by consensus, but by a developer hierarchy (e.g.  people like
Brion or Tim making final calls). Now a days it seems like things have
shifted more to managers at WMF make the decisions. How controversial
decisions are decided in our community is a complex topic unto itself.
I'm not even sure what the current best practise is, to be honest.

 And they don't feel responsible for what
 gets released on Wikimedia sites necessarily.

I strongly dispute that statement. If they didn't care, this thread
wouldn't be here.

In essence, the controversy is a bunch of people saying: I feel
responsible for what gets released on Wikimedia sites, and I believe
that the problems of TR don't outweight the benefits, or that it
otherwise doesn't meet the high standard of what normally gets
released, etc


 We can gain more consistent, accessible typography across languages with an
 iterative approach that continues to build on what we've done over the last
 five months. Or we can go back to the drawing board to try and please
 everyone, which is an impossibility if you ever want to make progress.

Sorry to put this so bluntly, but to be frank, its debatable whether
this actually represents progress.

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

On 4/7/14, Steven Walling steven.wall...@gmail.com wrote:
On Mon, Apr 7, 2014 at 5:46 PM, Brian Wolff bawo...@gmail.com wrote:

I totally agree. I don't see how there is any indication this is
functionally broken or a major regression across languages, keeping in mind
the necessity of ULS et al still. What major language-related bugs have
been raised that would not be present regardless for most default
sans-serifs?

I see some cases, such as CJK, where users may not prefer the serif
headings, since serifs look closer to a brush script in those languages
than they do in Latin languages. That doesn't seem to be what we're
discussing though? When it comes to the body font settings and language
support, we've been able to remove some local overrides. Some others, like
Persian, had Common.css overrides long before the new version was released.
The general state of affairs before *and* after is that there aren't
great-looking, freely-licensed fonts with support across all languages and
which are widely installed on our most popular OS/device combos. We're
making incremental improvements here.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I don't speak any non-latin languages, so I'm not competent to judge.
I based my comment on a large number of complaints I'm seeing.
Including Erwin Dokter's email earlier in this thread, and comments on
wiki like: I really really hate it. New fonts are really awful for
non-latin languages. [1]

[1]
https://commons.wikimedia.org/w/index.php?title=Commons:Village_pumpoldid=120885231#Changes_to_the_default_site_typography_coming_soon

--bawolff

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

Re: [Wikitech-l] Free fonts and Windows users

On Mon, Apr 7, 2014 at 7:27 PM, Brian Wolff bawo...@gmail.com wrote:

   We can gain more consistent, accessible typography across languages
 with an
  iterative approach that continues to build on what we've done over the
 last
  five months. Or we can go back to the drawing board to try and please
  everyone, which is an impossibility if you ever want to make progress.

 Sorry to put this so bluntly, but to be frank, its debatable whether
 this actually represents progress.


+1. Not all change is forward progress. Sometimes it's backward progress.
We usually call such motion a regression in MediaWiki :)

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

Re: [Wikitech-l] Free fonts and Windows users