This was done to avoid having the idieresis clash when doubled in Ukrainian. But there might be a way to make the dieresis which is a less egg shaped and a bit boxier which stands out from the dot on the I less.

This set of much boxier round shapes for the dieresis at the top looks much better to me and is exactly the sort of thing I was suggesting. It gives more even color and retains the clarity Roboto needs.

This is a cool idea of course not least because it nearly preserves the spacing of the dots in a normal dieresis. But I think it is fatally flawed for a few reasons - If you want to track the text out (or in) a ligature cannot take on the new treatment and so it interrupts the rhythm of text. That was accepted before ( like in the 1900-1950's) but I think it would stand out as odd now. - I am not 100% convinced that this would consistently be read correctly and not cause confusion for a reader. We don't as far as I know have evidence one way or the other so a radical solution in a workhorse design seems unsuitable to me. - in the case of required ligatures ( fl and fi ) the main reason we have them is to make sure hard encoded texts that use them won't break. I do think that the compressed dieresis looks odd and suboptimal outside of a doubling of the idieresis ( e.g. ïï) so what about an OT calt solution that swaps the compressed dieresis version in but only when it is doubled? It might be that some caps plus ï combinations such as Fï or Tï or Vï Wï Yï could benefit from a swap too.

I had better make sure there is a Calt feature in Merriweather for this.

Vika Grabowska pointed out that the її (or in Glyphs yi-cy yi-cy) is a combination that comes up in Ukrainian Cyrillic texts frequently being used in a female pronoun - 'she' if I recall correctly! So she argued that it should just be the narrower form of dieresis in Cyrillic as the default not as a localization. It might be that other Cyrillic scrip using languages also use yi-cy or u+0457 too - but if they do I don't know about them. It would be worth consulting Hyperglot. But as of now, I have followed Vika's advice. It certainly makes the OpenType code a little less complex. Does anyone have any counter arguments? For Latin, I am happy using CALT in part because I already understand the code and because I don't think of Word as being a reasonable benchmark now. They could turn on Calt by default as *it was supposed to be* but they haven't. I think as a type designer if MS/Word choose to be an OpenType support outlier I don't think it quite behooves me cater to that choice. Also how much Word editing is really happening in a browser now anyway? And do browser rules rule over questions of Open Type support in that context or do they suppress CALT there too? Maybe I am being excessive here but without a lot of heat, instead a shrug really, I can't quite see worrying about this - unless MS asked me to make the font in question. Still, in order to do the CCMP I think you would make a prefix in Glyphs like in Source Serif 4 called 'lookup_0' because why not copy it? The text in the prefix would be *lookup* lookup_0 { *sub* idieresis *by* idieresis.narrow; } lookup_0; Then I think CCMP code would be *lookup* ccmp0 { *sub* [idieresis]' *lookup* lookup_0 [idieresis] ; *sub* [idieresis.narrow] [idieresis ]' *lookup* lookup_0 ; } ccmp0; Look right to you all? I'll test this and see what it does when I have a CALT running too and without. The CALT code is just *sub* idieresis' idieresis *by* idieresis.narrow; *sub* idieresis.narrow idieresis' *by* idieresis.narrow; The CALT code ( and CCMP I guess) could be expanded to cover things like ïī or ïȉ or ïĵ etc. Any visual clash at all could be catered to or it maybe should be limited to things that we know actually occur?