Adlam font duplicate

[sommerluk]

Currently, our font list has Noto Sans Adlam (with letters that are joining up like Arabic) and then Noto Sans Adlam Unjoined (as the name says, with letters that do not join up).

As far as I understand, both fonts cover the same range of Unicode code points. Therefore, as we are vendoring fonts now and all fonts in our list will actually be available, the second one (Noto Sans Adlam Unjoined) will never be used, so obviously such duplicates should be removed.

Here is how these two fonts should render (screenshot of a PDF created with Scribus):

Above the joined version, below the unjoined version.

Wikipedia says:

The letters are found either joined akin to Arabic or separate - the joined form is commonly used in a cursive manner; however, separate or block forms are also used as primarily for educational content.

The link specified as source by Wikipedia however does not say that.

The Noto documentation says:

The unjoined variant is suitable for headlines and for educational content. The cursive variant, in which letters join the same way as in Arabic and N’Ko, is suitable for most texts. Needs software support for complex text layout (shaping).

Apparently, support in the shaping engine HarfBuzz was added in 2017.

Obviously, this is working today in up-to-date HarfBuzz versions, as my Scribus example shows. It also works in KDE’s text editor and in LibreOffice. However, it does not work in Mapnik:

Noto Sans Adlam is supposed to join, but does not join in Mapnik:

As comparision, here is Noto Sans Adlam Unjoined (which is similar, but not identical):

I don’t know why it doesn’t work in Mapnik.

In any case, it doesn’t make sense to keep both fonts. What should we do?

• Keep the joined font, knowing it will not actually join in current Mapnik, but maybe will join in later Mapnik versions.
• Keep the unjoined font, making sure that the rendering will not change, even if later Mapnik versions will support joining.

Note that the text in the example is 𞤪𞤢𞤤𞤵𞤆 𞤥𞤢𞤤𞤣𞤀 (diplays probably in wrong order Github): I did not find a real-world example in OSM, and therefore used this artificial example.