A question, primarily for our Dutch friends:
Is every instance where í is followed by j in Dutch going to necessarily be a stressed ij digraph?
Is there a preferred solution for deploying a special precomposed glyph with double accents for the stressed digraph?
Or is it best to just count on the user to input /iacute/j/acutecmb if they specifically want a properly stressed ij (and handle it with a contextual decomposition of the j and subsequent mark positioning of the /jdotless/acutecmb sequence)?
Any thoughts about best practice are welcome.
1
Comments
No, but it is extremely rare if you can assume that the language indeed is Dutch. The one example that is being repeated is ‘Fúji? Nee, Fíji.’ IIRC, Dutch orthography requires the hyphenation of i-j at borders of composed words if it is not the lange ij, e.g., safari-jeep or gummi-jas.
As for the preferred solution, I implement both. It should certainly be inserted in the ‘Unicode-correct’ way, no doubt. But there is no comfortable way for most users to enter the correct Unicode sequence, and some environments do not support ccmp and/or mark position properly. So, the precomposed digraph (/iacute_j.NLD) is more compatible for the way people will use it.
There also is another option, preferred by some, namely to add a precomposed /jacute, and replace /j with it after an /iacute. This makes tracking possible. But personally, I prefer the /iacute_j.NLD solution, exactly because it does not track (and I think most people will agree that it shouldn’t).
Given this, would it make sense to not put any such rules in {locl} — which is usually not turn-offable — and instead register it as language-specific within the {calt} or {liga} (depending upon which strategy one adopts)?
That way, in the rare case where the general assumption about the digraph is not accurate, there is at least the option for the user to override.
For example:
And in this jacute paradigm, I would also include a lookup in {ccmp}:
This {ccmp} would have to precede the {calt} so that in the case of the /iacute/j/acutecmb input sequence, the j.acute substitution intercepts the j before it gets targeted by the contextual substitution (which would leave an orphaned acutecmb visible in the rendered text).And, I suppose, if there is a preceding {ccmp} rule to decompose j followed by marksAbove, then the {ccmp} substitution would need to account for dotlessj acutecmb also or instead.
Thoughts?
— In loclNLD, replace i and j by i.loclNLD and j.loclNLD in LOCL. This blocks /fi ligatures and the likes and primes these letters for what's to come.
— In CALT, replace j.loclNLD after iacute by j.acute. This only happens when loclNLD is active, since j.loclNLD doesn't occur otherwise.
— In DLIG, replace iacute j.acute by the iacute_jacute ligature (for those who like ligatures).
This should work correctly out of the box for most situations. For Fíji, one can simply deactivate CALT on that word. The ligature only appears when you deliberately switch it on.
It seems to me that tracking/letterspacing is a circumstance which clarifies best practice.
Which is best, 2, 3, or 4?
http://www.underware.nl/blog/2014/10/typesetting-the-dutch-ij/
It is actually allowed (mainly for technical reasons –although it looks better too IMHO) to put an acute only on the i: https://onzetaal.nl/taaladvies/advies/klemtoonteken-nadrukteken
In the first, second, and fourth row there is the default spacing. In the third row the space between the i and j has been reduced by 10/1000 units. The type in the fifth row has been tracked with 100/1000 units. In the sixth row no tracking only for the I_J and in the seventh row I applied some optical corrections on the I_J and E_N combinations.
Point 1 has been discussed at length already at other places, and as demonstrated in this thread there is no consensus among Dutch type designers and typographers about the ideal shape or spacing. Depending on the design of the typeface I might decide to draw a special uppercase /IJ digraph. In some cases I might even add a dedicated shape for the lowercase /ij digraph although that has been quite rare.
On the other hand in almost all typefaces so far I’ve put a dedicated kerning pair for the /i/j combination to put them it a little bit tighter.
With regard to point 2 – the rules for emphasis are very clear and explained on https://onzetaal.nl/taaladvies/advies/klemtoonteken-nadrukteken. Vowels that consist of more than one letter will have an accent on each letter: dóé, gewóón, úít, nóú.
Therefore the /i/j combination shall not be treated any differently.
Do any of the rest of you make a localized effort to intercept ligation with the i when it is part of a Dutch /i/j sequence?
I think the issue would be fairly straightforward in the case where the encoded ij has been entered into the text stream intentionally. At that point it is easy to target and becomes more of a design question than a feature-coding challenge.
But otherwise, . . . ? Should the i.NLD become a regular strategy, like the i.TRK?
Is there a consensus on just how terrible it is to have an f_i ligature getting into what should otherwise be an ij digraph? Or has the average Dutch reader just come to accept that nowadays and it’s not worth jumping through hoops to prevent. Should we be leaving it to the typographer to enter an encoded digraph if she wants to reliably avoid the ligation? (And then address the fitting of the /f/ij combination either with a contextual alternate or kerning.)
Which could then prevent f-ligation with ij digraph when entered as /i/j sequence. (But, of course, also when not intended as digraph — e.g., bijoux.)
I’m not necessarily advocating. I was just asking, since it came up in Christian’s example.
Rob says that he doesn’t feel that the f-ligation with ij digraph needs to be avoided. I’d be interested to hear other opinions (or see more Agree flags on Rob’s post).