Download source for Noto Emoji does not work any more

[pjduplooygis]

Hi guys

I m trying to install openstreetmap-carto with docker.

With the import part of the process, I get the following error with the get-fonts.sh script:

[/tmp/get-fonts.hSJCbY7G5/Noto_Emoji.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/get-fonts.hSJCbY7G5/Noto_Emoji.zip or
/tmp/get-fonts.hSJCbY7G5/Noto_Emoji.zip.zip, and cannot find /tmp/get-fonts.hSJCbY7G5/Noto_Emoji.zip.ZIP, period.

When I run the script manually, I get the same error.

I have done this successfully less than six months ago (the date of the last change of the get-fonts.sh script), so it presumably is not a fault on your side. Did Google perhaps change something in the file?

Is there another download location, or how can this be overcome?

Pieter

[imagico]

I have done this successfully less than six months ago (the date of the last change of the get-fonts.sh script), so it presumably is not a fault on your side. Did Google perhaps change something in the file?

I did not look at this in more detail but probably Google started preventing automated downloads. If i use the URL we use in the script (https://fonts.google.com/download?family=Noto%20Emoji) in the browser it works - but not via curl/wget. Hence i can confirm this issue.

Maintenance of the download sources for fonts is annoying - see also #4893. Ideally we should have one or two fallback sources to get a font from if the primary source fails. But that is of course a lot of work to set up.

[pjduplooygis]

Would it be at all possible to include the fonts (the Emoji ones), in the git repo somewhere, and maybe let the script copy it over somehow?

Are there any restrictions on including these fonts?

QGIS had a similar problem with I think Open Sans

[imagico]

Would it be at all possible to include the fonts (the Emoji ones), in the git repo somewhere, and maybe let the script copy it over somehow?

Theoretically yes, practically we lack the resources to maintain that (and the style repository is probably not a good solution for that anyway).

A reasonable solution would IMO be if the OSMF would make available the font files they use in their deployment for download. Historically they have done the same for the coastline shapefiles - see https://planet.openstreetmap.org/historical-shapefiles/. So if you want to lobby them in that regard... We could then use that as a fallback location in get-fonts.sh in case font downloads from the regular places fail.

But of course any of the other users of OSM-Carto are also welcome to support the project by publicly making available a copy of the font packages with the commitment to have them there for any OSM-Carto users to get as needed.

QGIS had a similar problem with I think Open Sans

Well - QGIS has about a billion times the budget we have - so... 😉

[pjduplooygis]

Hi.

As a workaround I have done the following:

1. I have uploaded the Emoji font to archive.org.
2. Updated the get.font.sh script for that line to read:

curl --fail -A "get-fonts.sh/osm-carto" -o "${TMPDIR}/Noto_Emoji.zip" -L https://archive.org/download/noto-emoji/Noto_Emoji.zip

Script now works. The caveat is that downloads from archive.org can be a bit slow, but at least it is a workaround.

I tried curl --fail -A "get-fonts.sh/osm-carto" -o "${TMPDIR}/Noto_Emoji.zip" -L 'https://archive.org/download/noto-emoji/Noto_Emoji.zip' (note the '...'), but that does not work, so one must not include the ' '.

I am now going to run the docker bit, and see if that works

I hope it helps a bit finding a solution.

Regards
Pieter

[pjduplooygis]

Update:

Install now works perfectly.

I am leaving up the archive.org link if you want to use it

[imagico]

Thanks.

Yes, this will help people to deal with the acute problem.

I should probably have made it clear that the main problem is not making available the files statically, it is keeping them up-to-date with upstream changes. This is what the script we have is meant to facilitate.