Re: polytonic Greek: diacritics above long vowels á¾±, á¿‘, á¿¡

From: Richard Wordingham <richard.wordingham_at_ntlworld.com>
Date: Mon, 5 Aug 2013 21:46:19 +0100

On Mon, 5 Aug 2013 03:09:37 +0200
Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:

> 2013/8/4 Richard Wordingham <richard.wordingham_at_ntlworld.com>

> > They are missing from the set of precomposed characters. (It's been
> > argued that, in an ideal world, *all* precomposed characters would
> > be missing.)
 
> Of course you could argue that, but then the number of characters to
> encode would have been tremendous,...

The Latin script would have far fewer characters if precomposed
characters had been kept out. If they had been kept out, they would
*all* be missing.

> and we would have not been able
> to benefit from the normalization stability.

We might have benefited from an abandonment of NFC.

> You ould also argue that
> normalization stabiity was not needed for this case, but then it
> would have been extremely difficult to define conformant processes
> (i.e. the assertion that applications are trating all canonical
> equivalents the same way, except for binary sorting those subsets of
> canonical equivalents).

The requirement is that conformant processes not think they are doing
the right thing by treating canonically equivalent strings
differently. If there is latitude in a process, e.g. rendering, I
can't find a requirement to treat canonically equivalent strings
identically. Can you?

> > > They are not needed in fact, but they just should be documented
> > > somewhere for implementers of renderers and fonts, to support
> > > these types of clusters.
> >
> > Assuming that fonts containing COMBINING DOUBLE BREVE are not
> > required or morally obliged to support it properly.
> >
>
> I have not said this was required. That's why I suggested NOT a
> normative addition in TUS, but an evolutive, informative technical
> report instead.

> > May be it will be enough to include them somewhere in CLDR data
> > > (notably if they are still not listed explicitly in the Greek
> > > collation table),

> > The CLDR does not yet support Ancient Greek! It's by no means
> > certain that COMBINING DOUBLE BREVE would make it to the list of
> > auxiliary exemplar characters. Vowels with plain COMBINING BREVE
> > and COMBINING MACRON don't make to the list of auxiliary exemplar
> > characters for Modern Greek.

> I was not speaking about exemplar character subsets for any language,
> or even their auxiliary subset. Even if the last one is not
> standardized and evolutive, it is based on frequency of use and
> someagreements that these characters are desirable under common
> conventions, and that theiruse will be understood with minor efforts.

I believe I have seen a claim that CLDR data should only concern itself
with exemplar characters.

> > On the contrary, a simple remark in TUS Section 7.9 (precise
> > location is an exercise for editors who like to make it difficult
> > to cite) that diacritics over two base characters are not limited
> > to the Latin script should suffice. It's covered by 'pronunciation
> > systems' in TUS 6.2 - they're not limited to the Latin script. I
> > did notice some cases of ties apparently being used in annotated
> > Greek to indicate that a sequence of consonants counted as a single
> > character for metrical purposes.
 
> Where did I write that it should be limited to Latin ?

You didn't. You suggested a vast number of guides on rendering, when
diacritics acting on two base characters are already covered pretty
well by TUS. The only problem is that the discussion in the TUS might
be taken to imply that they would be restricted to Latin characters.

> You won't have neough flexiblity with the existing CLDR examplar
> subsets per language (and CLDR does not focus on non-linguistic uses
> such as technical and epigraphic notations, or phonetic/phonologic
> notations, or specific uses in multilingual texts, including texts
> that represent simultaneously several languages or optional readings).

Which is why I think CLDR is the wrong context for this.

Richard.
Received on Mon Aug 05 2013 - 15:50:06 CDT

This archive was generated by hypermail 2.2.0 : Mon Aug 05 2013 - 15:50:09 CDT