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

Host fonts in repository #79

Closed
kylebarron opened this issue Mar 5, 2020 · 8 comments
Closed

Host fonts in repository #79

kylebarron opened this issue Mar 5, 2020 · 8 comments

Comments

@kylebarron
Copy link
Contributor

I'm curious how you'd feel about hosting fonts in this repository. It might make it slightly easier for people to use the style.

Currently, glpyhs points to

"glyphs": "https://api.maptiler.com/fonts/{fontstack}/{range}.pbf?key={key}"

which means someone can't use the style without adding a maptiler api key, or self hosting their own fonts.

As an example, in this repository I just store several fontstacks from openmaptiles/fonts releases in the git repository unzipped. That means I can just put glpyhs as

"glyphs": "https://raw.githubusercontent.com/kylebarron/openmaptiles-fonts/master/fonts/{fontstack}/{range}.pbf",

and serve them directly from Github.

So similarly, you could add the Roboto fontstacks to this repository (optionally on a non-master branch), and then host them directly from this repo.

@orangemug
Copy link
Member

@kylebarron this repo used to use https://github.com/orangemug/font-glyphs and we changed it to use maptiler.com, see 9baf0ad

I think that's the correct decision since we are relying on the service for sources anyway. I guess the question is how does it make it easier?

With regards to using raw.githubusercontent.com for requests that isn't really allowed, this is because GitHub don't want you to use them, that's what GitHub pages is for. If the linked repo gets popular you're likely to get blocked earlier than you would with GitHub pages which they'll accept a lot higher number of requests before throttling/blocking.

GitHub will politely ask you to move you hosting off GitHub pages if it gets super popular (https://help.github.com/en/github/working-with-github-pages/about-github-pages#usage-limits), basically they won't host files for free with unlimited bandwidth, they are however very generous. It'll also be slower than GitHub pages because GitHub pages is behind a CDN (fastly I believe)

Note that you can also use https://www.jsdelivr.com/?docs=gh which @pathmapper changed for the styles in the editor https://github.com/maputnik/editor/blob/fea0798349580c200dac9827d24f2bc5c9811866/src/config/styles.json this is fast because it uses 'all the CDNs' (see https://www.jsdelivr.com/network/infographic)

I do have an interest/dream of a 'github hosted open source style' based off of natural earth tiles (thinking a good base map for news). I think in that situation, in repo glyphs might make more sense because everything would be easier to take offline.

@kylebarron
Copy link
Contributor Author

In my experience, I was new to maps, trying to self-host OpenMapTiles, and was really confused about how to host the non-map assets, like fonts and sprites. But maybe you're right and this is more suited to an explanatory blog post instead of changing the default glyphs source.

I didn't know using raw.githubusercontent.com wasn't allowed. And wow jsdelivr looks really cool. I'll probably change my endpoints to that.

Natural earth tiles are helpful, but they only exist at zooms up to ~7, right?

Also, sorry if this is the wrong place to mention this but http://orangemug.co.uk/ is down for me.

@orangemug
Copy link
Member

In my experience, I was new to maps, trying to self-host OpenMapTiles, and was really confused about how to host the non-map assets, like fonts and sprites. But maybe you're right and this is more suited to an explanatory blog post instead of changing the default glyphs source.

Yeah I definitely feel the pain. Also map styles aren't very 'forkable'. I think it comes from mapbox-gl-js being quite a 'production ready' format, both glyphs and sprites are bundled formats which make the difficult to deal with in general. I have made some progress with making plugins for mapbox-gl-js that make styles more 'development by default', I'll share some private repos if you're interested?

With regards to switching back to using the repo instead of the maptiler api, your point is totally valid I think I'd be confused how to self-host. Either way I think a blog post would be awesome! Thoughts @pathmapper ?

Natural earth tiles are helpful, but they only exist at zooms up to ~7, right?

I can't actually remember what zoom level but you're right it's quite low. But probably good for lots of datavis work. Sorry that was slightly off topic 😀

Also, sorry if this is the wrong place to mention this but http://orangemug.co.uk/ is down for me.

Thanks for letting me know, Maputnik takes up most/all my free time coding at the moment, http://orangemug.co.uk/ was a casualty. I hope it'll come back as a mapping blog in future when I find some more free time.

@kylebarron
Copy link
Contributor Author

kylebarron commented Mar 9, 2020

Yeah I definitely feel the pain. Also map styles aren't very 'forkable'. I think it comes from mapbox-gl-js being quite a 'production ready' format, both glyphs and sprites are bundled formats which make the difficult to deal with in general.

Somewhat related, what do you think about having sprites being auto-generated from master using Travis CI? Right now, if anything in svgs/ is updated, that won't update the sprite unless the sprite is manually generated. Travis could pull spritezero and generate the sprite, though I'm not sure how to best serve the compiled assets.

I have made some progress with making plugins for mapbox-gl-js that make styles more 'development by default', I'll share some private repos if you're interested?

Sure. Though I use react-map-gl, so I don't know how to use any mapbox-gl-js plugins with it.

I can't actually remember what zoom level but you're right it's quite low. But probably good for lots of datavis work. Sorry that was slightly off topic 😀

Could be good for low-zoom datavis. For datavis at higher zooms, I still think OpenMapTiles is helpful, especially since for an open source project you can host their 2017 planet extract for free, for example.

@pathmapper
Copy link
Member

With regards to switching back to using the repo instead of the maptiler api, your point is totally valid I think I'd be confused how to self-host.

Both are having pros and cons, e.g. the maptiler api offers currently a lot more fonts for map designers compared to https://github.com/orangemug/font-glyphs.
It's fine for me to switch back if someones feels this would be better; I have no strong opinion here.

Either way I think a blog post would be awesome!

👍 could be also added to https://github.com/maputnik/osm-liberty#usage

@kylebarron
Copy link
Contributor Author

the maptiler api offers currently a lot more fonts for map designers

I see that as a general plus, but since osm-liberty only uses Roboto, it doesn't seem like it's an argument against hosting from the repo.

As of release 2.0, Metropolis and PT Sans are also included.

It's not a big deal for me either way, though I will try to write up a blog post in the near future about self-hosting.

@pathmapper
Copy link
Member

having sprites being auto-generated from master

There is now a GitHub Actions workflow for building and deploying the sprites -> #116

@pathmapper
Copy link
Member

We are using https://github.com/orangemug/font-glyphs again -> closed by @zstadler in #125

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants