Support j-acute

[frankrolf]

The j-acute is for emphasis in Dutch.
For instance: https://twitter.com/j_acute/status/794437856781537280
See also: https://www.flickr.com/groups/jacute/

I would appreciate it if @LettError would suggest a preferred implementation.

[miguelsousa]

Glyphs tutorial about it https://www.glyphsapp.com/tutorials/localize-your-font-accented-dutch-ij

[frankrolf]

http://typedrawers.com/discussion/comment/16838/

[LettError]

I'll collect some points.

[frankrolf]

@LettError Do you have any suggestions for me?

[frankrolf]

I addressed this in a similar manner as Scope One does:
https://github.com/daltonmaag/scope-one/blob/master/source/ScopeOne_Rg.ufo/features.fea#L236-L239
If Dutch is set as the text language, the sequence of iacute + j will be replaced by iacute + dotlessj + acutecmb. This seems to be the least obtrusive solution.
I decided against a global substitution, because the sequence iacute + j seems to occur frequently in Slovak.

For the moment, the solution does not work in InDesign, but I have successfully tested it in Chrome and Firefox. Better than nothing I suppose!

[LettError]

This is probably too late, but why not have iacute + j + acutecmb translate to iacute + dotlessj + acutecmb. It records the intention that the j should indeed have an acute. I know that actually typing the acutecmb is not trivial and the asymmetry between the input of the iacute and jacute is ugly. But there are (theoretical) cases in Dutch where the j should not get an acute. `Bedoel je Fúji? Néé! Fíji!"

[frankrolf]

I see. Probably a semantically cleaner solution – however I wonder what the real benefit would be. The j-acute then would be hidden quite deeply, to a point where users probably would again not use it.

If we go for the solution you suggest, we should also create a Dutch keyboard layout which has the j + acutecmb sequence encoded for a single key stroke (easily possible). Thoughts?

[frankrolf]

Also, if I recall correctly, j + acutecmb automatically converts to j́ (without the dot). No OT feature would be needed then.

[LettError]

If such a keyboard layout could mimic the dead key behaviour that is used for the iacute (alt+e then i on a EU macos kbd). Alternatively I've thought about constructing one of Andy Clymers minikdb devices to generate that sequence on pressing a key.

[frankrolf]

I created a modified Dutch keyboard layout, it should be what Erik is thinking of:
Dutch_modified.keylayout.zip

[frankrolf]

Experimental support for j-acute is available in the latest release:
https://github.com/adobe-fonts/source-serif-pro/releases/tag/2.007R-ro%2F1.007R-it

Please report in case of unexpected/suboptimal behavior!

[moyogo]

Please report in case of unexpected/suboptimal behavior!

@frankrolf @LettError
This breaks a lot of Dutch texts by assuming all Dutch text must follow the current official rules.

The current spelling rules for marking stress were settled in the 1996 spelling.
Before that there were competing rules and a common one was to only repeat the stress mark on repeated letters, for example dáár, één or móói had two marks but níet, níeuwe, móet or zíjn had only one mark. These spellings with one mark are still very frequent, the official spelling being only mandatory in Belgian and Dutch government and public education. Current usage is still split.

The j-acute then would be hidden quite deeply, to a point where users probably would again not use it.

Unless the acute is there, there is no way to know if the user wanted it there.
Since the j́ is on iOS/macOS/Android Dutch keyboards and since more fonts support it, there is a higher frequency of its use in Dutch texts.

Omitting the acute on the j is explicitly tolerated in the official spelling.
See the 2005 spelling rule with "Due to technical limitations, the stress mark on the j of a lange ij is usually omitted. For example: blíjven kijken!" The example without the acute on j would not be displayed as intented or as published in law with fonts that add the acute.

[LettError]

(All those rules, even the newer ones, keep repeating "technical limitations" that clearly no longer exist. That might be a useful thing to talk to the TaalUnie about.)

This breaks a lot of Dutch texts by assuming all Dutch text must follow the current official rules.

Which this do you object to @moyogo?

The j + acutecmb is part of the exemplars in Unicode CLDR.

[moyogo]

(All those rules, even the newer ones, keep repeating "technical limitations" that clearly no longer exist. That might be a useful thing to talk to the TaalUnie about.)

Unfortunately there are still common fonts that fail at displaying j́ properly.

This breaks a lot of Dutch texts by assuming all Dutch text must follow the current official rules.

Which this do you object to @moyogo?

@LettError I’ve given up objecting at this point. This as in sub iacute j' by j_acutecomb and its variants that assume all "íj" in Dutch need an additional acute. One needs to be aware that when doing this by default in Dutch, they are breaking as much as they are trying to fix with it, not just a few corner cases like Fíji, foreign place names or people names.

The j + acutecmb is part of the exemplars in Unicode CLDR.

Yes, it was missing and reported in https://unicode-org.atlassian.net/browse/CLDR-6575.
The same goes for iOS/macOS/Android keyboard layouts, j́ was added because it was reported.
I don’t think I was the only one doing those reports back then.

[LettError]

Had to look up the source, this is issue:

    lookup IJ_ACUTE {
        script latn;
        language NLD exclude_dflt;
            sub Iacute J' lookup locl_NLD_ijacute;
            sub iacute j' lookup locl_NLD_ijacute;
    } IJ_ACUTE;

Maybe time for an update.