[predefined-counter-styles] ambiguity or insufficient specification for Latin-based Oromo-Qubee counters (#47)

verdy-p has just created a new issue for https://github.com/w3c/predefined-counter-styles:

== ambiguity or insufficient specification for Latin-based Oromo-Qubee counters ==
- [lower-oromo-qubee](https://www.w3.org/TR/predefined-counter-styles/#lower-oromo-qubee)
- [upper-oromo-qubee](https://www.w3.org/TR/predefined-counter-styles/#upper-oromo-qubee)

The "alphabetic" algorithm is not supposed to generate the same sequence for different integer values.
But the alphabetic symbols that are doubling vowels (like 2=aa) cause problems (we get also 38=aa).

I think there should be some separator (e.g. an hyphen) inserted when appending sequences of symbols that could be misinterpreted (such that 38="a-a").

The "alphabetic" algorithm and its specification not offer such warranty, and does not specify an option to conditionally insert separators, when some alphabetic symbols are already a concatenation of several valid symbols in the defined set.

This means that the valid range for the current specification of Oromo-Qubee is 1-38 (but there's no valid range specified, so that it could fallback to decimal by default)

Or may be "AA" is wrong for the value 2 (similar case for "EE", "II", "OO", and "UU"), and it should be a ligature (using ZWJ in the middle?) or more complex cluster, with diacritics like "A͡A" or "A͠A", or joined by a distinctive separator like "A·A", or using superscript as appended or prepended modifiers like "Aª", or "ªA".

Note that other digrams used in Oromo-Qubee like "CH" do not cause problem, because even if "C" is a valid numeric symbol, "H" alone is not but used only as an appended modifier.


Please view or discuss this issue at https://github.com/w3c/predefined-counter-styles/issues/47 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 5 July 2022 11:27:49 UTC