Developer - Capitals with diacritics not shown

L.S.
I have created a touch layout that works well for the most part. The shift layer looks like this:


The capitals with diacritics are all composed, i.e. (u_186 + u_0300) etc.

Testing the top-line in Chrome from left to right produces this:

And I can confirm that the actual compiled and installed keyboard on the telephone produces the same result. Composed Capitals with diacritics do not produce on the screen.

Any suggestions ?

PS. See the code below:
c

c Minuscules

c

platform(‘touch’) + [T_00AB_2039] > U+00AB U+2039 c ?

platform(‘touch’) + [T_203A_00BB] > U+203A U+00BB c ?

platform(‘touch’) + [T_025B_0300] > U+025B U+0300 c LATIN_SMALL_LETTER_OPEN_E with low tone

platform(‘touch’) + [T_025B_0301] > U+025B U+0301 c same with high tone

platform(‘touch’) + [T_0254_0300] > U+0254 U+0300 c LATIN_SMALL_LETTER_OPEN_O with low tone

platform(‘touch’) + [T_0254_0301] > U+0254 U+0301 c same with high tone

platform(‘touch’) + [T_014B_0301] > U+014B U+0301 c eng with high tone

c

c Majuscules

c

platform(‘touch’) + [T_0190_0301] > U+0190 U+0301 c LATIN_CAPITAL_LETTER_OPEN_E with high tone

platform(‘touch’) + [T_0190_0300] > U+0190 U+0300 c same with lowigh tone

platform(‘touch’) + [T_0186_0301] > U+0186 U+0301 c LATIN_CAPITAL_LETTER_OPEN_O with high tone

platform(‘touch’) + [T_0186_0300] > U+0186 U+0300 c same with high tone

platform(‘touch’) + [T_014A_0301] > U+014A U+0301 c LATIN_CAPITAL_LETTER_ENG with high tone

c

c dummy

c

c + [T_new_null] › NULL

Is it possible you have another set of rules that take precedence? Otherwise, could you send me the keyboard for checking? Use the usual sil.org email syntax.

Since +[T_xx] rules are only used for the touch interface anyway, I don’t see a reason to add platform(‘touch’) in the context. Not that this would cause the problem, but just seeking to simplify the code.

Ok that is good to know. I remember, back a looong time ago I did some programming for the 68000 cpu and we were taught to write lean-and-mean code because this would make the executable quicker. Now, these big keyboard files with lots of stores that serve many languages in a whole country or region, are they in fact slower then a trimmed-down keyboard file just for one or two languages? (Maybe a question for Marc …) And would it thus make sens to have a lean-and-mean keyman keyboard file just for the local and the national language?

So far, your issue confuses me EVERY SINGLE TIME. You need a shift in your rules. This works for me:

 + [SHIFT T_0190_0301] > U+0190 U+0301 c LATIN_CAPITAL_LETTER_OPEN_E with high tone
 + [SHIFT T_0190_0300] > U+0190 U+0300 c same with lowigh tone
 + [SHIFT T_0186_0301] > U+0186 U+0301 c LATIN_CAPITAL_LETTER_OPEN_O with high tone
 + [SHIFT T_0186_0300] > U+0186 U+0300 c same with high tone
 + [SHIFT T_014A_0301] > U+014A U+0301 c LATIN_CAPITAL_LETTER_ENG with high tone
1 Like

Yes, that was the problem. Thank you Lorna. Much relieved.
Bart

1 Like

The performance of keyboards is not an issue on modern devices – there are other reasons to consider it though, which I see you’ve taken up on another thread :smile:.