[css-text-3] correct implementation of full-size-kana

[dpino]

I recently attempted to implement full-size-kana in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1498148).

I have some doubts regarding which kana characters should be transformed from small to normal size. Appendix G (Small Kana Mappings) (https://drafts.csswg.org/css-text-3/#small-kana) of "CSS Text Module Level 3", provides a set of small kana and their mappings to normal size kana.

However, Florian’s spec of full-size-kana (https://specs.rivoal.net/css-custom-tt/#full-size-kana) provides a much larger mapping of kanas. This is interesting as the example of transformation provided at #3143: しゃ into しや is covered by Florian's specification of full-size-kana but not by the Appendix G of the draft. Is it likely the list of mappings provided in Florian's spec will be finally merged in the draft?

On the other hand, the list of kanas listed in https://specs.rivoal.net/css-custom-tt/#full-size-kana is missing 2 mappings:

'ㇺ' => 'ム' (Katakana Small Mu => Katakana Mu)
'ｯ' => 'ﾂ' (Half-width Katakana Small Tu => Half-width Katakana Tu)

[upsuper]

I don't see any problem in Appendix G. I wrote a small script to match the appendix table and the example in Florian's document, and it seems the only difference is that ｯ is missing from Florian's one, otherwise they are identical.

[upsuper]

For reference, below is the script I wrote for this:

#!/usr/bin/env python3

mappings = """
ぁ U+3041	あ U+3042
ぃ U+3043	い U+3044
ぅ U+3045	う U+3046
ぇ U+3047	え U+3048
ぉ U+3049	お U+304A
ゕ U+3095	か U+304B
ゖ U+3096	け U+3051
っ U+3063	つ U+3064
ゃ U+3083	や U+3084
ゅ U+3085	ゆ U+3086
ょ U+3087	よ U+3088
ゎ U+308E	わ U+308F 
ァ U+30A1	ア U+30A2
ィ U+30A3	イ U+30A4
ゥ U+30A5	ウ U+30A6
ェ U+30A7	エ U+30A8
ォ U+30A9	オ U+30AA
ヵ U+30F5	カ U+30AB
ㇰ U+31F0	ク U+30AF
ヶ U+30F6	ケ U+30B1
ㇱ U+31F1	シ U+30B7
ㇲ U+31F2	ス U+30B9
ッ U+30C3	ツ U+30C4
ㇳ U+31F3	ト U+30C8
ㇴ U+31F4	ヌ U+30CC
ㇵ U+31F5	ハ U+30CF
ㇶ U+31F6	ヒ U+30D2
ㇷ U+31F7	フ U+30D5
ㇸ U+31F8	ヘ U+30D8
ㇹ U+31F9	ホ U+30DB
ㇺ U+31FA	ム U+30E0
ャ U+30E3	ヤ U+30E4
ュ U+30E5	ユ U+30E6
ョ U+30E7	ヨ U+30E8
ㇻ U+31FB	ラ U+30E9
ㇼ U+31FC	リ U+30EA
ㇽ U+31FD	ル U+30EB
ㇾ U+31FE	レ U+30EC
ㇿ U+31FF	ロ U+30ED
ヮ U+30EE	ワ U+30EF 
ｧ U+FF67	ｱ U+FF71
ｨ U+FF68	ｲ U+FF72
ｩ U+FF69	ｳ U+FF73
ｪ U+FF6A	ｴ U+FF74
ｫ U+FF6B	ｵ U+FF75
ｯ U+FF6F	ﾂ U+FF82
ｬ U+FF6C	ﾔ U+FF94
ｭ U+FF6D	ﾕ U+FF95
ｮ U+FF6E	ﾖ U+FF96 
"""

mappings = [m.split() for m in mappings.strip().split('\n')]
mappings.sort(key=lambda m: m[1])
for m in mappings:
    print(m[0], m[1])
print()
for m in mappings:
    print(m[2], m[3])

smalls = "ぁぃぅぇぉゕゖっゃゅょゎァィゥェォヵㇰヶㇱㇲッㇳㇴㇵㇶㇷㇸㇹㇺャュョㇻㇼㇽㇾㇿヮｧｨｩｪｫｬｭｮ"
for s in smalls:
    found = False
    for m in mappings:
        if s == m[0]:
            found = True
            break
    if not found:
        print("not found in spec: " + s)
for m in mappings:
    found = False
    for s in smalls:
        if s == m[0]:
            found = True
            break
    if not found:
        print("not found in tt: " + m[0])

def to_u(c):
    code = hex(ord(c)).upper()
    return 'U+' + code[2:]
for m in mappings:
    if to_u(m[0]) != m[1]:
        print("wrong matching: " + m[0] + " " + m[1])
    if to_u(m[2]) != m[3]:
        print("wrong matching: " + m[2] + " " + m[3])

The two long strings are copied from the two specs correspondingly, and the first part for ordering the mapping is for easier reviewing in the Gecko bug.

[dpino]

Thanks for the feedback @upsuper. It seems that the problem was that my Google Chrome (Version 69.0.3497.100 (Official Build) (64-bit)) doesn't render all the list of kanas in Appendix G, however Firefox does. Why Google Chrome doesn't render all the list, I don't know.

I attach a screenshot.

[frivoal]

That looks like a multicol bug. multicol is used to make the table more compact it browsers that support it well, looking linear in Firefox, and like this in Chrome on my machine:

Not sure why it doesn't work right, but in the meanwhile, misreading the spec is bad, so I'll turn off this effect.

[frivoal]

Reverted the commit that caused that (cc @fantasai)

[frivoal]

it seems the only difference is that ｯ is missing from Florian's one, otherwise they are identical.

That's an unintentional oversight in my spec. I've just fixed it.

[dpino]

Thanks for the feedback. I'm closing the ticket since the doubts I raised in the issue has now been clarified.