Publish the style, samples and fonts to GitHub Pages on release

[HuggeK]

Summary

This PR is what publishes the site at all. The repo's Pages source is set to GitHub Actions (build_type: workflow), but the workflow that does the deploying lives here and has never been merged — so nothing has deployed since 5 July 2026. https://huggek.github.io/golfTiles/ is still serving that day's build, which is why the MapLibre v6 fix in #53 had no visible effect after merging.

It replaces the hand-synced copies in docs/ that kept going stale:

• New publish-pages.yml workflow — runs on every push to main, on every published release, and manually via workflow_dispatch. It assembles the site from canonical sources at build time: docs/index.html, the canonical styles/golfTilesStyle.json, docs/samples/*.pmtiles and docs/fonts/, then deploys with actions/deploy-pages.
• Self-hosted font glyphs — vendors Open Sans Regular SDF ranges into docs/fonts/, served at https://huggek.github.io/golfTiles/fonts/{fontstack}/{range}.pbf. GitHub Pages sends Access-Control-Allow-Origin: *, so the same URL keeps working once golftiles.org serves the style.
• Deletes the stale docs/styles/golfTilesStyle.json — the workflow publishes the canonical style instead, rewriting its pmtiles source URL and its glyphs URL to the Pages origin with jq.
• Modernizes docs/index.html — relative URLs, MapLibre v6, and the same pitch/navigation/terrain controls as the golftiles.org demo.

Updated since this PR was first opened

• Merged main in, including the MapLibre v6 (ESM) migration from Migrate the demo pages to MapLibre GL JS v6 (ESM) #53. The one conflict was docs/index.html, where this branch had independently pinned maplibre-gl@5.24.0 — the same diagnosis Migrate the demo pages to MapLibre GL JS v6 (ESM) #53 reached, one major earlier. Resolved to v6's import * as maplibregl, keeping this branch's Pages-relative URLs, controls and rebranding.
• The workflow now rewrites glyphs as well as the pmtiles URL. Previously docs/fonts/ was copied into the site but the canonical style on main declares no glyphs, so nothing ever requested those files and labels silently fell back to locally rendered glyphs. This makes the PR self-sufficient rather than depending on First version of the style: terrain, water, roads and per-course hole colors (#7) #49 landing first.
• Glyphs regenerated from the current Open Sans and relicensed to OFL 1.1.
• Only the 16 non-empty ranges are committed, down from 256.

Font: what changed and why

The ranges previously came from openmaptiles/fonts, which still builds the pre-2021 static Open Sans TTFs under Apache 2.0. They are now generated from current upstream — the variable ofl/opensans/OpenSans[wdth,wght].ttf in google/fonts — which has been SIL OFL 1.1 since the March 2021 release. docs/fonts/LICENSE.txt (Apache) is replaced by OFL.txt, published at /fonts/OFL.txt, and the demo page carries a visible credit.

Being a variable font buys nothing at runtime: MapLibre consumes pre-baked SDF ranges and the style spec has no font axes, so FreeType bakes the default instance (wght 400, wdth 100 = Regular) at build time. It is simply the current, correctly-licensed upstream.

256 files → 16. The clutter was never the font: 240 of the 256 ranges are ~32-byte empty stubs for scripts Open Sans does not cover. Only the 16 blocks that contain glyphs are committed. Total glyph data is about the same (~392 KB → ~429 KB — slightly up, since the new font covers two more blocks); the win is file count, not size.

A missing range 404s rather than returning an empty file. MapLibre handles both identically — one warning, then it renders that codepoint locally — and since the omitted blocks have no glyphs anyway, nothing renders differently.

Generated with MapLibre's own font-maker WASM, the engine behind https://maplibre.org/font-maker, so the output is the same as the official tool's. docs/fonts/README.md documents how to regenerate.

Why the style's pmtiles and glyphs URLs are rewritten at publish time

The canonical style points its source at pmtiles://https://golftiles.org/samples/…, but golftiles.org serves no CORS headers (the reason commit 3ff8bf0 originally forked a hand-edited copy into docs/). The workflow's jq step rewrites .sources.golfTiles_source.url to the Pages origin so the demo fetches tiles same-origin, and sets .glyphs to the ranges copied alongside.

Both rewrites leave styles/golfTilesStyle.json itself untouched, so this does not conflict with the style work on #49. The glyphs value it produces is byte-identical to the one #49 adds to the canonical style, so the two agree once #49 lands. jq also doubles as a JSON-validity gate for the style in CI.

Runbook

1. Flip the Pages source to GitHub Actions — already done; that is why the site is currently frozen.
2. Merge this PR. The push to main triggers publish-pages.yml, which deploys. Every future push to main and every published release republishes.
3. Verify https://huggek.github.io/golfTiles/ renders the map and labels.

#49 is no longer a prerequisite for labels — the glyphs rewrite above covers that. It is still needed for the terrain control (see below).

Known limitation until #49 lands

docs/index.html adds a TerrainControl bound to source terrainSource, which the canonical style on main does not define — that source arrives with #49. The button renders but would fail if clicked. Labels, tiles and everything else are unaffected.

Verification

Each page was assembled exactly as the workflow does (cp + the jq rewrites) and loaded in headless Chrome over the DevTools Protocol, served through a Range-capable server since pmtiles requires byte serving:

• maplibre-gl.mjs, maplibre-gl-shared.mjs and maplibre-gl-worker.mjs all load; the worker comes from the CDN cross-origin via MapLibre's blob module shim.
• pmtiles range requests succeed and tiles decode; the golf layers render.
• /fonts/Open Sans Regular/0-255.pbf returns 200 and the Emmaboda Golfklubb label renders — previously this range was never requested at all.
• /fonts/OFL.txt returns 200.
• Zero console errors and zero failed requests.
• The literal jq filter from the workflow was run through jq 1.8.2 against the canonical style.

Pre-existing issue seen while testing, not addressed here

layers[tees_borders].paint.line-color: Could not parse color from value 'yellow;red' Falling back to rgba(0,0,0,1) — looks like a raw OSM multi-value tag reaching the style. It renders black today. Left for a separate PR since it belongs to the style work.

🤖 Generated with Claude Code