If not, it *might* (or might not) try e + spacing acute as a next fallback. In heavily Unicode-savvy environments, this means that if the font doesn’t have a precomposed, say, eacute, it will then instead be asked “how about e + combining acute?” because that is canonically equivalent. Which I say because Unicode compliance in the real world is not just a binary switch you flip.) In the absence of the precomposed characters, apps/systems should look for the combining characters. Unicode specifies that for those precomposed characters which correspond to certain sequences of combining characters, they are “canonically equivalent” and should be treated the same way.
It’s an app, and it is using either its own or system-level services for Unicode support. It’s not “the font” responding when you type something. (Otherwise, the font won’t respond when an “i” is typed, right?) Nope. So, you still need to have some glyph present in the font to map 0x0069 to in the table. First of all, it’s very unlikely that any user (or keyboard) is inputting u+0131 plus u+0307 rather than just typing an “i” u+0069. That seems like a very cumbersome approach to me. I wondered if that might be so in several of the responses here. Ah, I took Nick to mean the second case (GPOS).
0 kommentar(er)
