search

OpenHistoricalMap / issues

File your issues here, regardless of repo until we get all our repos squared away; we don't want to miss anything.
Creative Commons Zero v1.0 Universal
17 stars 1 forks source link

Replace fontstack with something prettier and more multilingual #870

Open 1ec5 opened 1 month ago

1ec5 commented 1 month ago

In #359, we introduced an “OpenHistorical” family of fontstacks for map labels that pulls in Open Sans for the most common Western scripts and Unifont for everything else. Neither font is particularly attractive. This combination also lacks support for many of the historical scripts that we’re starting to expose in the vector tiles as part of #679. Imagine being able to navigate to Mesopotamia in the Bronze Age and see the names of places in both your language and cuneiform. Stuff like that would be an eye-opener in historical GIS. Unfortunately, our fontstack doesn’t cover cuneiform codepoints, so OpenHistoricalMap/openhistoricalmap-embed#8 draws a blank.

OpenStreetMap Americana used to piggyback off OpenHistorical but quickly outgrew it and created an alternative fontstack and toolchain, fontstack66, based on the Noto project. The various fonts under the Noto umbrella add up to much wider Unicode coverage than Unifont, and they all look pretty attractive compared to Unifont. We could fork fontstack66 and supplement it with the extra Noto fonts we care about, then configure the site to publish that fork alongside the map-styles repository (from which we currently serve up font PBFs).

Any support for historical writing systems would require a change being discussed in maplibre/maplibre-gl-js#4550 to request glyph PBFs for codepages above U+FFFF.

1ec5 commented 1 month ago

We could fork fontstack66 and supplement it with the extra Noto fonts we care about

The default configuration already includes some non-BMP codepoint ranges, but we’d need to add some more fonts like Noto Anatolian Hieroglyphs and Noto Cuneiform that probably wouldn’t make a ton of sense for OSM Americana to serve from their domain. After adding the fonts to the configuration, we’d configure GitHub Pages to publish to openhistoricalmap.org similar to how the map-styles repository gets published. Apart from that, I don’t anticipate needing to manage a fork as part of the main deployment process. It would be the same level of maintenance overhead as openhistoricalmap-embed, if not less.