When coding in Dutch, ij should not look like a single narrow letter.

[moyogo]

The current feature code sub i j by ij and sub iacute j by ijacute;, and the equivalent substitutions for capitals in the locl NLD for Dutch are an anti-pattern, especially in coding context.

The current Google Sans Code shows ij in an unexpected manner in monospace context when applications are showing code in Dutch:

In comparison Noto Sans Mono shows ij as expected:

This patch disables the locl NLD feature and replaces the sub iacute j by ijacute; in locl NLD by sub ij acutecomb by ijacute; in ccmp default.

For example:

Doing such a substitution is an anti-pattern, it is counterproductive and break things rather than solve the problem it is trying to solve. The Taalunie, the standard body in charge of the Dutch language, considers ij to be a digraph i+j that behaves like a letter in some contexts, for example in crosswords (ij in one cell) or when capitalized at the beginning of words (IJzer). There are also cases where ij is purely a digraph, for example in foreign or borrowed words. There is no reason it should be a narrow letter by default, in particular when the characters IJ and ij are available for that purpose.

The acute on the j is usually omitted, as described in the official spelling rules, it shouldn’t be added by the font if it’s not in the character string. The standard way to have the j with acute is to use the combining acute with j. The current feature code breaks both:

[kalapi]

Thanks for the patch and the insights, @moyogo!

Would you not do this is a proportional typeface either and handle it using stylistic sets?

Thanks in advance!

[moyogo]

@kalapi 👋🏽
I don’t recommend doing this in a proportional font either.

The Glyphs app Dutch localization tutorial removed the sub i j by ij recommendation a long time ago. The sub iacute j by ijacute should also stop being recommended, it was intended for users who have no other options not for the general case where a digraph or only one acute may be intentional. It’s beyond me why they haven’t updated the tutorial to reflect the latter as well.

Stylistic sets are adequate for these two behaviours in some styles. It’s not clear if there’s a use case for a monospace coding font.