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

How to distribute Styles? #10

Closed
lukasmartinelli opened this issue Sep 28, 2016 · 7 comments
Closed

How to distribute Styles? #10

lukasmartinelli opened this issue Sep 28, 2016 · 7 comments

Comments

@lukasmartinelli
Copy link
Collaborator

An important part of Maputnik will be to share styles with each other. The JSON is perhaps enough - perhaps not and we need a ZIP file for having local fonts and glyphs.

We just need to think about how people can share their styles.

@orangemug
Copy link
Collaborator

I have also been thinking about offine usage of styles. Basically what I would like is for a styles to define all the assets they require to be functional offline. Basically so they can be downloaded by

  • A desktop client
  • A server on first deploy
  • A service worker to be put in the browser cache

How about adding a manifest with information about where the different assets are available for download?

@lukasmartinelli
Copy link
Collaborator Author

How about adding a manifest with information about where the different assets are available for download?

Don't have a solution ready... Happy to accept proposals - no opinions on my side yet.
Just that enduser experience matters. Users must be able to share editable styles. Only this way we can get people to play.

With Mapbox Studio Classic there was the tm2z format that bundled everything.
In the GL spec the styles just point to the asset URIs (sprites and glyphs). This is already enough to pull down the data (if you want to do caching only).

I am not sure a manifest is necessary. The GL style already has all the information - or you can add metadata there as well. A manifest on the other way would be a bit more generic if later we want to export a OL3 style function (then loading the plugin from #7 is only necessary in the editor).

As long as you would ship the generated glyph PBFs and the sprites it is not so difficult.
But perhaps one wants to ship the source assets with the styles, so it is easy to share and modify.

@orangemug
Copy link
Collaborator

I am not sure a manifest is necessary. The GL style already has all the information

I guess only if you can recursively download the assets, which you can't with the following for example

"sprite": "http://osm-liberty.lukasmartinelli.ch/sprites/osm-liberty",
"glyphs": "https://orangemug.github.io/font-glyphs/glyphs/{fontstack}/{range}.pbf" 

As long as you would ship the generated glyph PBFs and the sprites it is not so difficult.

This will mean you end up with lots of styles with slightly different versions of typefaces over time

I'll work on a spec of my ideas around the manifest tomorrow you can see what you think

@klokan
Copy link
Member

klokan commented Nov 17, 2016

Related repo: https://github.com/klokantech/gl-style-package-spec
Feel free to create tickets there to move the ideas forward

@lukasmartinelli
Copy link
Collaborator Author

@orangemug generates the font artefacts via Travis and stores it in GitHub pages from the repo https://github.com/orangemug/font-glyphs which is a cool idea.

@orangemug
Copy link
Collaborator

orangemug commented Nov 18, 2016

@lukasmartinelli there is also a v2 in the works that supports any font from google fonts (I'll make it public next week)

Edit: Now public orangemug/font-glyphs#1 (comment)

@lukasmartinelli
Copy link
Collaborator Author

From the Maputnik side of view still all I care is a style.json.

Fonts and glyphs must be managed externally (yes that is not ideal but these features can only be provided by a hosted platform or a server appication).

nyurik pushed a commit that referenced this issue Feb 12, 2024
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