Last modified: 2014-10-09 08:49:33 UTC
Noto is a font family from Google's internationalization team. Its goal is "to achieve visual harmonization (e.g., compatible heights and stroke thicknesses) across languages. Noto fonts are under Apache License 2.0. Our current plan is to support all living scripts in Unicode by the end of 2014." <https://code.google.com/p/noto/>
The fonts(default and options) for each language is based on bug reports/requests from community. Whether noto font can "replace" the current fonts for languages as requested by community is not really a question the team can answer. See https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Selection_of_fonts But WMF Language Engineering team is in contact with Google team, we even had face to face meetings in 2012. We do have a story card to add these fonts as optional fonts https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/3621 - of course this has to be done by per language investigation and communication with community.
(In reply to comment #1) > The fonts(default and options) for each language is based on bug > reports/requests from community. This is not persuasive. First, it is not always clear what is being requested. For example, the first request-url for Amiri cites <https://bugzilla.wikimedia.org/41359>. The request in comments #7 and #10 is simply for the font to be made available by the extension, not loaded automatically. But then there are comments #11, #16, and #18: > As there are problems with including the fonts. I request the extension to > be disabled, because it is of no use now on the AR wikis. > Hi, WebFonts might be causing long pages to overload; can it be made into > a gadget? > Now, the webfont extension is displaying the Amiri webfont for all users, > because of some rendering issues related to Windows perhaps, I suggest > showing the webfonts only for users who selected them. Second, you did not anticipate the performance impact of loading web fonts, and thus could not have represented it fairly to the community. The requests from the community were thus made in ignorance of the trade-offs involved. Third, with all due respect to the autonomy of, say, the Arabic Wikipedia, I do not think that they can decide how Arabic font should be rendered in articles on the French Wikipedia. In fact I would imagine that the requestors would be surprised to discover that their request was used to underwrite this decision. The Noto font family could be used on each wiki to provide support for all languages which are not the primary content language.
(In reply to comment #2) > First, it is not always clear what is being requested. > Second, you did not anticipate the performance impact of loading web fonts, > and > thus could not have represented it fairly to the community. The requests from > the community were thus made in ignorance of the trade-offs involved. > Third, with all due respect to the autonomy of, say, the Arabic Wikipedia, I > do > not think that they can decide how Arabic font should be rendered in articles > on the French Wikipedia. In fact I would imagine that the requestors would be > surprised to discover that their request was used to underwrite this > decision. The first point is always a risk and it often takes endless back and forth communication and evaluations to come to some understanding. You would already know this. The languages other than the one for which the performance impact was already analysed, i.e. languages with open requests for fonts, we are going to rely heavily on the guidelines that Santhosh has been putting together: https://www.mediawiki.org/wiki/Universal_Language_Selector/WebFonts#Selection_of_fonts > The Noto font family could be used on each wiki to provide support for all > languages which are not the primary content language. This means the Noto fonts would also have to be evaluated similarly. If you think we could address things beyond the items in the previous link, you could suggest them directly on the page. It would be of immense help to add more perspectives. Thanks.
@Nemo, the script coverage document is out-of-date. You can see that it has massively expanded: <https://code.google.com/p/noto/source/detail?r=237>
(In reply to Ori Livneh from comment #4) > @Nemo, the script coverage document is out-of-date. You can see that it has > massively expanded: <https://code.google.com/p/noto/source/detail?r=237> That's not very useful. Can we have a pretty table like these? * https://www.gnu.org/software/freefont/coverage.html * https://sourceforge.net/p/dejavu/code/HEAD/tree/trunk/dejavu-fonts/langcover.txt
(In reply to Nemo from comment #5) > That's not very useful. Can we have a pretty table like these? > * https://www.gnu.org/software/freefont/coverage.html > * > https://sourceforge.net/p/dejavu/code/HEAD/tree/trunk/dejavu-fonts/langcover. > txt If there isn't one already, perhaps the sources can be adapted: http://math.sut.ac.th/lab/software/texlive/texmf-dist/doc/fonts/gnu-freefont/tools/report/range_report.py
Found by chance today: https://wikimedia.mingle.thoughtworks.com/projects/language_engineering/cards/4421?version=2
CC Yurik given https://gerrit.wikimedia.org/r/#/c/165698/1 (http://unifoundry.com/unifont.html ) No response on https://code.google.com/p/googlefontdirectory/issues/detail?id=297 :(
