Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change default value for text-font to Noto Sans Regular #311

Closed
bdon opened this issue Aug 22, 2023 · 24 comments
Closed

Change default value for text-font to Noto Sans Regular #311

bdon opened this issue Aug 22, 2023 · 24 comments

Comments

@bdon
Copy link

bdon commented Aug 22, 2023

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

"Open Sans Regular",

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

maplibre/maplibre-gl-js#2990
maplibre/maplibre-gl-js#1051
maplibre/font-maker#16

@HarelM
Copy link
Member

HarelM commented Aug 22, 2023

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
Copy link
Author

bdon commented Aug 22, 2023

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

@HarelM
Copy link
Member

HarelM commented Aug 22, 2023

I can't argue with that...

@wipfli
Copy link
Member

wipfli commented Aug 22, 2023

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
Copy link
Member

HarelM commented Aug 22, 2023

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
Copy link

pnorman commented Aug 22, 2023

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
Copy link

+1

@zstadler
Copy link
Contributor

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
Copy link
Member

HarelM commented Aug 23, 2023

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
Copy link
Contributor

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

@ianthetechie
Copy link

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

@neodescis
Copy link
Collaborator

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
Copy link
Member

HarelM commented Aug 25, 2023

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

@tordans
Copy link

tordans commented Aug 25, 2023

I was wondering how different the fonts look:

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

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
Copy link
Collaborator

louwers commented Aug 25, 2023

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
Copy link
Member

HarelM commented Aug 25, 2023

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
Copy link
Member

wipfli commented Nov 13, 2023

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
Copy link
Member

HarelM commented Nov 13, 2023

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
Copy link
Member

wipfli commented Nov 13, 2023

Sounds good.

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

@neodescis
Copy link
Collaborator

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

@HarelM
Copy link
Member

HarelM commented Nov 13, 2023

Sure, both suggestion are fine by me.

@neodescis
Copy link
Collaborator

neodescis commented Nov 13, 2023

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
Copy link
Author

bdon commented Nov 13, 2023

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 added a commit to bdon/maplibre-style-spec that referenced this issue Dec 4, 2023
* Change it from Open Sans Regular, Arial Unicode MS Regular which does not have a freely licensed reproducible build.
@bdon
Copy link
Author

bdon commented Dec 5, 2023

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

@bdon bdon closed this as completed Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants