Change default value for text-font to Noto Sans Regular

[bdon]

Design Proposal: Change the default value of text-font.

Motivation

The current default text-font if no value is specified is Open Sans Regular, Arial Unicode MS Regular

https://github.com/maplibre/maplibre-style-spec/blob/d6654968fbbf59dd0ab1dc7c5e4e8d2ae7298081/src/reference/v8.json#L1783

The issues with this current situation:

• The Arial Unicode MS font is proprietary, and users of MapLibre generally do not have a license to this font, making this default useless.
• It requires two fonts for sufficient coverage of the Unicode BMP, since Open Sans has only Latin, Greek, Cyrillic and Hebrew.

Proposed Change

Change the default value to Noto Sans Regular. This is an openly licensed font designed for maximum coverage, and can be made available for most MapLibre users.

API Modifications

This is a breaking change if users depend on the old default behavior. There shouldn't be many, unless their client is fetching from Mapbox.

Migration Plan and Compatibility

This should accompany a major version release of maplibre-gl-js and maplibre-native, because of the change in default value behavior.

Rejected Alternatives

• There are other font families like Source Sans and DejaVu with the same goals. Those are viable alternatives.

Related Issues

https://github.com/maplibre/maplibre-gl-js/issues/2990 https://github.com/maplibre/maplibre-gl-js/issues/1051 https://github.com/maplibre/font-maker/issues/16

[HarelM]

I don't have any objections, but there isn't a near future plan to release a major breaking change version. Version 3 was released a few month ago, so I would aim this for early next year, what do you think?

[bdon]

That's perfectly fine, we can revisit this at at a later date - just seems odd to have an unusable default

[HarelM]

I can't argue with that...

[wipfli]

Good idea in general, but this would be a breaking change in the style specification which I think we should avoid. Or am I missing something?

[HarelM]

Technically yes, but if you relay on the default font you are probably doing something wrong. It is best practice to define the font and make sure you serve it from your server. Much like specifying the icon and making sure it is in the sprite. Generally speaking, in most cases, as described here nothing will show up if you don't specify the font, so I think it's better than current situation...

[pnorman]

Technically yes, but if you relay on the default font you are probably doing something wrong. It is best practice to define the font and make sure you serve it from your server.

Yes. Specifying fonts needs to be done in conjunction with specifying the URL for fonts, so defaults make little practical sense.

[jonahadkins]

+1

[zstadler]

Another alternative is to avoid having a default text-font and issue an error if a layer does not set it. A similar error is currently produced if glyphs is not set for the style.

Several components have to be set and served properly in order for the text to show. Having a default for text-font without a default glyphs that contains the default font, makes little sense to me. I find having no default to be a much safer approach.

[HarelM]

Another option is to have a style property of "global default font" in order to reduce the need to specify the font for every label and allow override this when you want to set a different font for a specific label. This will remove this hardcoded definition and allow changing it. This property can have the current default, and later on have a different one which can make the trasition easier, maybe...

[zstadler]

I think this option can, and should, be incorporated with any of the alternatives: changing the default or removing the default all together.

[ianthetechie]

I like the approach of removing an implicit default and permitting an explicit default to reduce “noise.”

[neodescis]

I also like not having an implicit default. Having to specify the font stack for every layer is indeed tedious, so I like the idea of adding an explicit, user-specified default for all layers.

Also, this is tangential, but while we're talking about changing the spec for fonts anyway... I have run into situations where it would be nice to serve different font stacks from different URLs. This can currently be accomplished using a request transform, but it would be nice if the style spec supported specifying different URLs for each font stack. I think this could be done in such a way as to be a non-breaking change.

[HarelM]

I would recommend opening a different discussion around multiple glyph urls.

[tordans]

I was wondering how different the fonts look:

Noto Sans	Open Sans
https://fontsource.org/fonts/noto-sans	https://fontsource.org/fonts/open-sans

It looks like the font weight but also the default line height change noticably.

Does anyone have some real live examples? Maybe with white text on dark which will likely make the thinner weights more visible…

[louwers]

if you relay on the default font you are probably doing something wrong.

By this reasoning we should remove the default, and not change it.

[HarelM]

My suggestion here it to change the behavior from implicit to explicit default - i.e. have it declared and not hard coded. This will require a definition of what is the value of this parameter if it's not specified, and we can leave it as it is today in order to avoid breaking stuff...

[wipfli]

I think making the global default font configurable with the default set to the current value is a good idea. Like this we can avoid a breaking change to the style specification but still have an easy way to configure a global default font.

What should the new property look like?

[HarelM]

Since the property is called text-font I would think that default-text-font as a top level property should address this need (array of strings). We can set Noto Sans Regular to be the first one and Open Sans Regular to be the second one, i.e. ['Noto Sans Regular', 'Open Sans Regular'] this way the default would cover more characters while still falling back to the original default. It might change the appearance in cases where you forgot to add a font and Noto is available.

What I suggest is:

1. Add this property to the spec
2. Set the current default in maplibre-gl-js 3.x to be Open Sans Regular
3. Update this default to ['Noto Sans Regular', 'Open Sans Regular'] for version 4.x

[wipfli]

Sounds good.

Shouldn't the new default be ['Open Sans Regular', 'Noto Sans Regular']?

[neodescis]

How about text-font-default instead? IMO it'd be better to name/sort/group things by functionality than having a defaults section.

[HarelM]

Sure, both suggestion are fine by me.

[neodescis]

Also, does an array of strings actually cause MapLibre to fall back when something isn't found? I thought that was something that happened server-side in mapbox land. Not that I wouldn't welcome such functionality!

[bdon]

It does not fall back on the client, you need to build a fallback by generating a static fontstack with multiple TTFs, or dynamically composing them, and then putting a comma in the fontstack name.

[bdon]

Closing to avoid backwards-compatible changes with limited benefit. Maybe for a future major revision...

[jcardus]

Another option is to have a style property of "global default font" in order to reduce the need to specify the font for every label and allow override this when you want to set a different font for a specific label. This will remove this hardcoded definition and allow changing it. This property can have the current default, and later on have a different one which can make the trasition easier, maybe...

This would be great. If you don't specify the text-font in your layers (which happens a lot) and you change the style to another vector tiles provider you will probably get a blank screen as most of the providers I tested (esri, here, amazon) don't host maplibre's default font.

The way around this for me was to change the glyphs url to my own (and host a lot of fonts) after the style is loaded. But it makes more sense to keep the original one included in the provider's style.

[hyperknot]

I don't understand why are we worried that it's a breaking change, since the users do not have the proprietary Arial fonts installed anyway. Basically thing are broken by definition here.

And no, I don't think Arial should be hosted by repos here, look at my ticket here: https://github.com/maplibre/maplibre-gl-js/issues/4820#issuecomment-2407187662

[HarelM]

How do you know they don't have this font? How can you be sure this won't break how this map looks?

[hyperknot]

How do they "have" Open Sans Regular, Arial Unicode MS Regular PBF files? The only way to get it is to download from one of the illegal repositories hosting these PBFs.

Even if you happen to have this font installed on your Windows machine, quoting Microsoft Font redistribution FAQ:

You do not have rights to: copy fonts from a Windows installation to a web server, a process known as web font “self-hosting”.

Basically no one has the right to host Arial fonts on the web.

I don't understand why is this project worried about braking a situation which is not even legal.

[louwers]

MapLibre Native has different font loading backends and it is able to load local fonts. It can for example use Arial Unicode MS Regular when Open Sans Regular is unavailable.

MapLibre GL JS will make a web request when loading a font (I assume). You could have a smart server with a fallback mechanism too, but the Open Sans Regular, Arial Unicode MS Regular PBF files we use for static hosting only contain one font: Open Sans Regular, not Arial Unicode MS Regular.