Reduce clutter by having fewer fonts?

[allefeld]

I think it's great that you have created a huge font family which covers all scripts/writing systems defined in Unicode 6.1, and are still working to expand coverage. Though I can't read anything beyond the latin script (and a tiny bit of Greek), I like having the Noto fonts installed on my computer, so that when I encounter e.g. a website in a non-latin script, it's not just a bunch of boxes.

However, a serious drawback of that is the clutter it creates in font menus. I'm on Debian 11, and I currently have only fonts-noto-core, fonts-noto-mono and fonts-noto-color-emoji installed, and I still have 193 entries in my font selection list!

Now I understand the point made in the FAQ that there is a limitation to the number of glyphs in a font. However, according to the list on Wikipedia, there are many Noto fonts which contain only a few hundred, or even a few dozen glyphs. So it should be possible to reduce the number of fonts considerably, e.g. by combining a number of linguistically or geographically related scripts into a single font. The FAQ states that there is a plan to do so

However, we are working on a possible repackaging of the fonts into a few files.

but if I'm not mistaken that entry is 5 years old. Does this plan still exist?

[simoncozens]

but if I'm not mistaken that entry is 5 years old. Does this plan still exist?

Hi, I'm Simon, and I've recently been commissioned by Google Fonts to work on Noto production engineering. Thanks for this question. It comes up a lot, so I'll try and give a detailed answer.

TLDR: Yes, the plan still exists, yes, we are actively working on it, but it's more complicated than it looks and it's going to take a while.

The Noto project has around 200 source files, separated into individual script projects. This makes sense because when you're commissioning or designing a script or Unicode block, you work to work on a coherent subset of the problem. Designers can work on a small, well-defined set of glyphs, and develop a font which looks good and behaves well for that particular script, without having to deal with a huge number of glyphs that don't concern them. In project management terms in makes sense to have them separated out. So there's no plan to merge Noto at the "input" side of things.

The issue is output - the compiled fonts that come out of the Noto project and get downloaded by users, installed onto devices, or delivered via CSS web fonts. So far, not a lot of effort has been put into optimising delivery. Each of the 200 source files have been compiled, tested and delivered as a separate Noto font - by hand. Again, this made sense in the early days of the project when you would commision a font, get it back from designers, build and ship it, and then gather feedback and ask for changes after a year or so. But with 200 script projects now in circulation, and with many issues coming in, doing that kind of "waterfall" approach manually is cumbersome, error-prone and a waste of people's time. It's kind of hard to think about reorganising delivery when you're spending a lot of time keeping up with changes and issues in the sources. We want to move to a more agile way of maintaining and delivering the fonts, and we've been learning a lot about continuous integration and delivery of fonts over the past couple of years. So the first order of business for me is to look at automating a lot of the production and delivery pipeline. This will mean reorganising the project and developing some new QA and release tools. I expect that will happen over the next two or three months.

Once the font building and QA is taken care of, then we can start to think more about what kind of outputs we want. We don't need to map each source project to a separate font. But what should the output fonts be? A recurring request has been for core Latin glyphs to be added to each font so that they can be used in mixed-script documents. As you've asked, it would also make sense to combine multiple fonts into a smaller number of deliverables.

Before we get to that, we need to think about the process of merging fonts. If we're going to keep the source fonts separate but merge them into smaller sets, we need reliable tools to do that. The existing font merging tool we use, pyftmerge, does a good job but is starting to creak. It works by gathering together every glyph from all the fonts you give it, and then working out how to select the glyph you mean based on things like script and language. So if I feed 200 Noto fonts to pyftmerge, I get 200 space glyphs, 200 sets of numbers, and so on. I know why it does it - selecting subsets of glyphs to merge makes the merging process much more complicated - but it's not really adequate for our purposes. We're also now delivering more of the Noto fonts as variable fonts, which pyftmerge doesn't handle at all. So we also need to specify and develop new tools to handle the merging process.

Once we've got our pipeline reorganised and new font merging tools, then we have to decide what smaller subsets make sense. There are lots of possible ways to do this and all of them have pros and cons; there's no clear obvious right approach. For example, you might want to take a geographical approach and merge scripts per continent or region. But scripts don't live in nice geographical boxes. A Noto Sans Africa without Arabic would not make sense. I live in the UK, where Latin is obviously the majority script but there are significant communities of minority script users. So should Noto Sans Europe include Bengali? Should historical scripts be included or placed into their own category? Is it justifiable to lump all the smaller scripts, with only a few glyphs in them, together to form a "Noto Sans Rest Of The World"? That leaves a really bad taste in my mouth; I believe every script is important, and that there are no lesser scripts and greater scripts. Delivering each script project independently is definitely cumbersome but it's also egalitarian - it doesn't privilege any script community above any other. So it needs thinking through, and all these decisions need to be made and backed up with data, research, and sensitivity to the needs and sensibilities of the user communities.

We will get there in terms of improving delivery, and I believe we will get there this year. But I want to do it well and get it right, so it's going to take some time.

[allefeld]

Thanks for the extensive answer!

[ChiefMikeK]

If this is to be a major change then it would probably help to archive AND LINK the Readme.md of Phase III and create a new new Repository for Phase-IV

[simoncozens]

Yes, this will happen; in fact I am anticipating that this repo will be deprecated and replaced by another form of delivery, probably through a GitHub pages website on notofonts.github.io (people who still want to download the whole set of binaries will still be able to do so by checking out that repo).

[Pi-Cla]

@simoncozens will Noto Fonts continue to ship with hinted TTF fonts? I ask as it seems many openSUSE users prefer them to unhinted OTF see: https://bugzilla.opensuse.org/show_bug.cgi?id=1199938
I am concerned as it seems like Noto CJK already does not have hinted TTFs anymore.

[simoncozens]

I don't think we ever had hinted TTFs of CJK, only OTFs. But yes, the new distributions will have unhinted and hinted. See https://notofonts.github.io for an example of what it will look like.

[Pi-Cla]

Oh that's good to know. Demo website looks neat

[r12a]

Sorry to be slow, but what does "Full" mean in the column headings?

[simoncozens]

Noto fonts typically cover a particular Unicode range, which makes them useful for documents exclusively in that range or when used as part of a typesetting stack (e.g. with browser fallback). But it's less useful when typesetting documents containing other ranges. The typical case is e.g. Arabic where you want to use Latin letters, symbols, numerals etc. So a full build of Noto Nastaliq Urdu would include a Google Fonts Latin Core subset of Noto Sans.

Other use cases for full builds are for example Sharada where you want to "borrow" Vedic symbols from Noto Sans Devanagari.

In other words, the normal build is just what comes out of the font sources, the full build is the one you probably want to use.

[r12a]

Got it. Thanks for the explanation.

Just an idea: something like 'Augmented' might be better than 'Full' (?)

[simoncozens]

Yeah, I'm aware it's not a very helpful name. Augmented is OK, but makes me think you need to use VR glasses to view it. "Plus"? I don't know. I'll keep thinking.

[ChiefMikeK]

IMHO "+core" would be more descriptive vice Full

[allefeld]

@simoncozens Is there an update to this?

[simoncozens]

We have the full builds working now and they're part of the releases, but I still haven't thought of a better way to segment the fonts without being discriminatory. OTOH, we have also introduced (for development/release staging purposes only) the concept of Noto "tiers" from 1-5, so maybe that bridge is already crossed. I should experiment to see if we could put all of each tier into a single font. There are some technological investigations around the idea of raising the glyph limit which may mean we can combine all of Noto into one font, but that'll be a way off.