Google Noto Fonts (opens in new tab)

Please understand that Han unification is _the_ problem. It is clean that Unicode needs to realize that the Han unification is wrong and accepts what the native writers of those languages think about their scripts.

To make the problem more understandable to the people that are used to alphabetic scripts, suppose that tomorrow an Asian committee starts creating Uniword, a repertoire that maps complete words to numerical IDs. At a certain point they get to "colour".

Uniword committee: Well, that word shares meaning and origin with the other word "color", for which we have already a codepoint, so we will encode them under the same codepoint.

GB, Australia and Canada: Ehi! No! To us those are different words; especially, we do not want Mr. Colours to appear as Mr. Color.

Uniword commitee: No problem, just add some out-of-band information like "nationality" or "<span lang='en-GB'>"

"colour"-people: that will not work, there are so many cases in which this can go wrong. Whenever I copy a field from a DB I also have to extract this extra information?

Uniword: yes, that is the problem? C'mon!

"colour"-people: but do you need to do that in your applications?

Uniword: no, we have one code for every single word in our languages, including codes for very old languages that exist only in two palimpsests.

"colour"-people: and why cannot we have the same level of granularity?

Uniword: because you have too many words!!! And we started we had only 100k available integers.

"colour"-people: and now?

Uniword: now we have 2^32. But, yeah, that is not the point; just do how we suggest. This dialog is getting to long.

"colour"-people: "dialogue", please.

Every discussion we ever had about going to Unicode: "Is it bidirectional compatible with SJIS?" "No." "OK, so when it breaks, what characters does it break on?" "People's names, mostly." "... And why is this being considered?" "It is very, very convenient for white people. Almost all of their stuff works out of the box."

It may not be so infuriating when you consider how important names are to Japanese people. Breaking your name is unacceptable and breaking it because of a technical convenience chosen during development would be deeply offensive on top of being unacceptable.

Until Unicode stops breaking people's names, it will continue to be the one standard for Japanese systems on and offline. Even when(if?) it stops breaking Japanese names, it will take a very, very long time to roll over existing systems and that's precluding unforeseen problems during the conversion.

We should stop before we take the "not following standard" = "broken" ideology. Especially when we consider whom the standard serves best.

Edit: By "it will continue to be the one standard for Japanese" in the 2nd paragraph, I meant ShiftJIS not Unicode. That looked a bit unclear.

The amount of Japanese systems that are SJIS only is staggering, basically all traditional IT (banks etc) uses it and does not support, nor will ever support, unicode.

This, naturally, has an impact beyond those systems' borders.

Oddly, the following more modest proposal hasn't gotten much traction: characters that share history but have divergent graphical representations in the various dialects of alphabetic script shall share codepoints, and a mechanism beyond the scope of Unicode (like lang attributes or plain guesswork) shall be used to decide whether a given codepoint means L or ᴫ or Λ or whatever.

I can, partially understand why the Japanese refuse to support Unicode. And while most just adopt unicode simply because of its convenient, it doesn't actually solve the problem behind the Hans Characters in different form and glyph.

Over the years, i am starting to think Han Unification is western ways of hacking the CJK Hans problem rather then actually solving it.

Eh, most Japanese people don't know/care about the problem of Han unification. It's mostly because of the legacy data. The thing is that ASCII and UTF-8 is kinda compatible with minor annoyances, while Shift JIS and UTF-8 are entirely different. People don't want to convert a trove of documents to another encoding which might not be supported yet in some apps. Slow software upgrade is another reason. As someone else pointed out, the default encoding of Windows is still Shift JIS, which is totally understandable for compatibility sake.

Edit: Besides, a TTF font doesn't have to always use Unicode internally. It supports an arbitrary mapping from bytes (could be in UTF-8 or SJIS) to a glyph number. People who really care about the looks (i.e. printing) have been using a charset for each specific language, such as Adobe-Japan1, which is different from both UTF-8 or Shift JIS.

There's some CJK sample on Adobe Typekit blog

http://blog.typekit.com/2014/07/15/introducing-source-han-sa...

Part of the problem here is that Japanese Windows using SJIS at its front end, perhaps for "legacy" compatibility issue... (Backend, like filesystem on modern Windows is Unicode; it was apparent when adding files containing Japanese characters into Git; it would work if I'm retrieving the file from another Windows machine, but horribly corrupted when moving to other platforms.)

Fortunately, Git guys added fix to convert it into Unicode internally.

Another problem is that while most japanese characters take 2 bytes in SJIS, they take 3 in UTF-8.

In their defense, when you click India and scroll down, it does say, "not supported yet". Which leads me to believe they picked both languages with few characters (or straightforward to render?) and those most common, and they'll get to the rest shortly. :)

Oriya appears to be quite complicated to render: http://www.microsoft.com/typography/OpenTypeDev/oriya/intro....

Meanwhile, I wonder if this means we'll see OCR and ePubs for all kinds of scripts now; or if this will help enable Google Translate in more languages? ;-)

It's probably just a matter of whether or not there's somebody in the relevant team(s) who is familiar with, or at least has heard of, any given script.

I wouldn't be surprised if there happens to be an Osmanya geek in Google, but none of his teammates has ever heard of Oriya. For the same reason, I wouldn't surprised if they added a bunch of geeky fictional languages before actual ones.

And the fun thing is, there is two OLD! persian script available, (Pahlavi, OldPersian Both dead for almost 1500 year) and the current Persian is not supported :)))

Perhaps even more curious is the inclusion of Deseret, a toy language developed by the Mormons in the early 1800s. It never caught on and few books other than the Book of Mormon were ever translated into it.

Good pick, but I also see the value in preservation — maybe 500 years from now, the Noto fonts will be the best or only representation of many dead or forgotten scripts and languages.

I noticed the inclusion of Cornish. As of 2011 there were 557 people that claimed Cornish as their primary language.

Hi fellow Oriyan, google has very bad support for Oriya,since IT is not that great as in R&D in odisha, I work in IIIT hyd, which is the leading NLP lab in India and I dont see anything in Oriya.

Good observation.

Well, one reason would be that your web font would be 134Mb or so? (looking at the size of the comprehensive Noto download)

The other is simple practicality - these things take time to develop, you can either wait until all the glyphs are done, or release subsets that cover languages as you work; a subset that covers part of a language isn't very useful but subsets that cover whole languages are.

They're not really "for" a language. They are optimized subsets of the same font that only contain glyphs from one or more languages to minimize the file size.

If your website is written in English and an occasional accented character from other Western languages, there's no need to load a 50MB web font containing all the Tradntional Chinese characters.

Part of the answer is that Unicode has a lot of characters, and web pages use only a few, so for web fonts it makes sense to have the user download only ones likely to be used.

Another part is that some CJK characters look somewhat different in C, J, and K. http://www.unicode.org/faq/han_cjk.html#3

CJK unification in Unicode means that you don't know how to render a Unicode codepoint without also knowing the language of the text - the same Unicode codepoint looks different when rendered in Chinese, Japanese or Korean.

There are technical reasons for this. For example m, OpenType only supports 64k glyphs within a font. Which is enough for the BMP but nothing else (and counting ligatures that are necessary for, e.g. Arabic, it might not even suffice for the BMP).

Then there are practical considerations. While Latin, Greek and Cyrillic are similar enough to warrant the same styles (serif, sans-serif, script, italic, and various weights) not all of them make very much sense for, say, CJK or a variety of other scripts. So having different fonts for different scripts that are still designed to go together is actually not that bad a solution.

It does mean that for good typography you need a matrix of fonts based on style and script. Word includes two fonts per style for this, to treat CJK differently, which might not be enough, depending on the numbers of different scripts involved in a single document. But a) several dozen scripts per document are somewhat rare apart from Wikipedia's language list per article and font demonstrations; and b) good typography needs effort, this won't change.

I would guess that it's because of the amount of work required to design glyphs for every character that retain the font's style while still capturing the character's look and meaning from its language.

According to the site all the fonts together are 134MB compressed. Maybe that's the reason or maybe because it's a work in progress so works out better in segments.

A typographer typically works within a small set of languages. It would be unfeasible for a single type foundry to cover every possible glyph with the same consistency.

A lot of fonts don't support a lot of unicode characters.

Could you file a bug at https://code.google.com/p/noto/issues/list ? This is a great place for @eteraz to get involved.

I saw the article before and I too was deeply moved by it, but don't you think you could word this better so as not to make it sound so blasé? "Pah, no nastaliq, useless!" -- this is an amazing project.

You can find a nice Nastaliq font at http://urdu.ca/1 (direct link: http://urdu.ca/UrduFonts.zip). More are available at http://www.urdujahan.com/font.html. You will want to find out how they are licensed before using them in a commercial capacity.

Big thanks to Google for this effort...

But true, no Nastaliq (yet). Sadly not even mentioned as "unsupported".

The Urdu font they currently have there is not too bad. I won't mind reading a passage in this font.

The Serif looks questionable to me as well. The vertical line on the lowercase 'h' in particular looks like it has artifacts, both too thick and oddly blurred. The Greek serif has a lot of the same artifacts as well. The sans-serif looks fine, but something looks pretty wrong with the serif. I also thought it might be a client-side rendering issue (I'm using a Mac), but the demo page has the text prerendered into an image.

edit: Found a different demo page that renders the webfont client-side instead of showing images, and looks much better to me: http://www.google.com/fonts/specimen/Noto+Serif. Maybe it's just that the pre-rendered specimens are made with a poor rendering engine?

It looks awfully blurry in Firefox on Linux.

I thought Han Unification meant that (most of the common) CJK characters were represented by the same Unicode code points, and that the way to differentiate like this is by specifying metadata that indicates the "language".

Obviously I'm wrong, because these are just regular Unicode characters, without an HTML "lang" attribute.

What gives?

I wonder it could be split up, and the necessary segment(s) could be dynamically loaded based on OS language preferences?

For math Symbols: Cambria Math and DejaVu Sans should have them. http://www.alanwood.net/unicode/fontsbyrange.html#u1d400

That was an interesting comment. May I ask, as a follow-up comment, what you meant by

mathematical symbols from the SMP

as I did the expected Google search, and I am not sure that the search results I see refer to what you were referring to.

No technical reasons, but it would be unlikely for Apple or Microsoft to adopt a font made by Google, when their own alternatives exist, despite technical superiority. Android already uses Roboto, which has been heavily invested in for Android 4+ and now with Material design too. Of course, by Linux I'm assuming you mean the popular distributions of it like Ubuntu, but even Ubuntu has its own font which it is unlikely to change - other non-"branded" distros probably would be the only ones who might.

NotoSans/NotoSerif downloads have a LICENSE file which starts "Apache License Version 2.0, January 2004 http://www.apache.org/licenses/".

Apache 2.0, so yes.

Which itself is a redrawing of Droid Sans. This Typophile thread has some comparisons, and a couple comments by the designer, Steve Matteson: http://typophile.com/node/101655

It's just a shame that Noto Sans doesn't have a nice range of weights. They would of been better off improving Open Sans instead of creating yet another font.

Greek was spoken in Egypt for 1000 years. I imagine it's not that common today.

It has been for quite some time (at least a year).

https://www.google.com/fonts/specimen/Noto+Sans

If they released a monospace version, I would switch from Inconsolata! Although it is probably more important to continue work on supporting more languages.

I have the same effect on Safari for Mac. This is lame.

On my netbook, Firefox warned me about an unresponsive script.

Not so sure. Commandeering of my scroll-bar and slight enlargement of clicked element along with dark outer glow didn't sit well with me.

I suggest you file a bug https://code.google.com/p/noto/issues/list