On 4 Jul 2013, at 03:56, "Phillips, Addison" <[email protected]> wrote:
> I don't disagree with the potential need for changing the decomposition. That > discussion seems clear and is only muddled by talking about variant, language > sensitive rendering. That isn't the only consideration, right? No, Addison, we can't change the decomposition, That would invalidate all the data everywhere in Latvia. > I disagree that language tagging is not a valid means of getting language > specific shaping (which could solve a specific problem). This is hardly > confined to CJK or Latvian. Minority languages can, in fact, take advantage > of it, within reason (documentation is a problem and it presupposes that > glyph support is available). In fact, in some ways, language based glyph > selection is possibly easier to achieve because the number of implementations > is relatively small. The problem is in pretending that a cedilla and a comma below are equivalent because in some script fonts in France or Turkey routinely write some sort of undifferentiated tick for ç. :-) As far as I can see the only solution is: Mandate that only the comma-below shape is appropriate for Ḑḑ Ģģ Ķķ Ļļ Ņņ Ŗŗ despite their decomposition to cedilla. Encode a set of undecomposable Dd Gg Kk Ll Nn Rr with invariant cedilla for display of that glyph with those base letters. The only strangeness here is that D̦d̦ G̦g̦ K̦k̦ L̦l̦ N̦n̦ R̦r̦ with genuine combining comma below are confusable with the Latvian/Livonian letters, but that is already the case. > None of this addresses the problem of pain text representation or the > potential need to represent what are apparently different characters with a > single encoding. But if it is just presentation we're talking about... how > does this differ from, for example, Serbian vs Russian? What, the italic lowercase т? That is really not comparable to this issue. Michael Everson * http://www.evertype.com/
