Touch Device - Arabic Diacritics Proportionally very small

Keyman Keyman How To
1

Hello Team,

I have developed a bsk Keyboard with Perso Arabic script. It is working like a charm. However, I have a unique problem.

There is only one option for Font Size that would impact all the layers. I have a keyboard layer with only Arabic diacritics and it is very small, barely can be seen.

If I increase the font size for touch display in the keyboard then the non-diacritic characters go out of

view or break the keyboard due to the larger size. Is there any option I can increase the font size for only one key or one layer (The layer contain diacritic?

2 - I have another situation where I want to display Ű±Ù’ key and when a user presses this key, combination of U+0627 U+0628, it should output Ű±Ù’

Please let me know if you can help with the code.

IMG_1886
IMG_18861170×2532 184 KB

IMG_1885
IMG_18851170×2532 186 KB

image
image1171×718 115 KB

2

I found the solution to the 2nd part of my question by myself, reading on the forum. it was fairly simple.
I changed the keyboard version to 15 from 10 in the keyboard code. like this.
image
and then used the key combination like this.

image
image397×577 48.1 KB

3

Hi @sunny, welcome to the community.

Have you tried a different font for the touch layout? The default one is not always ideal.

4

Yes, I have used multiple fonts. The stand alone diacritics are very small.
As is the case with the arabic characters, they are small, medium and large. One font size for all characters is not ideal. At least, font size on each layer based should be allowed.

5

I have talked to my colleague about this and the way around for the time being is to use CSS manually from within Keyman Developer.

In the Details tap, you can add an “Embedded CSS” feature to the keyboard. Here is the example of how CSS can be used to format keyboard layouts: https://github.com/keymanapp/keyboards/blob/b409e4abd6eb625ed11f36aca0aebd3cd101a78d/release/gff/gff_blin/source/gff_blin.css.

6

For Font sizes,
We are used to using points (pts) for printed fonts (12pt for “normal” printed text, Arabic fonts are often illegible at 12pt and I’ve seen documents printed as high as 20pt.). The pt unit doesn’t always map well to screens of different sizes.

Specifically, I would suggest using em units in your keyboard, which are proportional to the “default” size. This means that whatever the size of the overall keyboard font, the specific characters will be proportionally larger (or smaller).

1em means the default size. 1.5em means 50% larger, .5em means 50% smaller.

In CSS, 50% larger for your diacritic keycap would be:

.tablet div.kmw-key.kmw-key-default[id$='U_0618']   
  { font-size: 1.5em }

Note: The CSS is applied only when the mobile keyboard is running (on your browser or phone), so you won’t see the size difference in Keyman Developer. If you want to see the same sizes in KMDev, you need to ALSO add a line to the key in the Touch layout’s code editor. Below is one of my special keys in the code editor that is 80% (0.8em) of the normal font size (because it has three side-by-side-characters).

image

@Makara I thought I knew KM formatting inside and out, but learned something today. I thought that the fontsize code in used in KMDev was applied before the CSS in the live keyboard, but now I see that that is not (or is no longer) the case. The two are separate. Is that a recent change?

7

@sunny , since you are working on a right-to-left keyboard, these links might be relevant and interesting to you:

8

Not that I’m a CSS expert, but I probably should be a better person to ask about that. Though
 uh, I’m not 100% clear on the observation and question. Are you saying that the fontsize code on the key is not applied at all within KeymanWeb outside of Keyman Developer testing? Or that it’s applied ‘after’ rather than ‘before’? Is there a keyboard I should try in both places to see the difference?

Also, what version of Developer and of KeymanWeb are you using? Are you using 17.0 alpha versions or 16.0? There’s a chance some 17.0 changes could have had an unwanted side effect, with this as our first observation, so it’d help to know.

9

Thank you all, I learned a lot from this discussion. I have now fixed all issues with your feedback and help.

2 Likes
10

I’m on 16.0.141. Screenshots are from SIL/Cameroon_Azerty
My T_CAM key (shown in the screenshot) is supposed to be 0.8em because it is several letters long. The in-code keyboard size
image

seems to only affect the touch-layout preview in the editor. I thought I remembered that it affected mobile, but in my testing, it does not. Maybe this code is deprecated, because it’s not configurable in the interface.

image

CSS affects the OSK and Touch keyboards, but has never been previewed inside KMDev.

Currently, I don’t have CSS resizing set up. You could test with "fontsize: “.5em” first to see if it makes it to the keyboard preview in your browser.

Then add a “font-size” style to my lines for T_CAM in the CSS and see what you get.

image
image1562×123 9.55 KB

11

Huh. I’m uncertain enough about the actual intent that I’m going to go ahead and open up an issue for it on the repository: bug(web): touch-layout fontSize appears to be ignored · Issue #9837 · keymanapp/keyman · GitHub. Apologies for not having a more immediate answer.