Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug(web): the in-app Khmer Angkor caption name doesn't fit on the OSK's Spacebar on mobile devices #11203

Open
1 of 8 tasks
bharanidharanj opened this issue Apr 10, 2024 · 8 comments
Assignees
Milestone

Comments

@bharanidharanj
Copy link

Describe the bug

I noticed that after installing the Khmer Angkor keyboard, the caption name does not fit on the OSK's Spacebar.

Reproduce the bug

  1. Install Keyman 17.0.303-beta.
  2. Open Keyman In-app.
  3. Download and Install Khmer Angkor Keyboard.
  4. Switched to Khmer Angkor Keyboard.

Here, I noticed the the Khmer Angkor caption name does not fit into the space bar key.

Note: It is working fine on Android OS.

..in Android Mobile

..in iPhone Mobile

Expected behavior

Khmer Angkor Caption name should be fully visible on the Spacebar key.

Related issues

No response

Keyman apps

  • Keyman for Android
  • Keyman for iPhone and iPad
  • Keyman for Linux
  • Keyman for macOS
  • Keyman for Windows
  • Keyman Developer
  • KeymanWeb
  • Other - give details at bottom of form

Keyman version

17.0.303-beta

Operating system

iOS 17.4

Device

iPhone 13 Mobile

Target application

No response

Browser

No response

Keyboard name

khmer_angkor

Keyboard version

1.3

Language name

Khmer

Additional context

No response

@jahorton
Copy link
Contributor

A comment on https://forums.developer.apple.com/forums/thread/128293 has the solution.

The actual problem: By default, the Safari WebView applies a minimum text size; if text is told to display smaller than that, it will force the font size to be larger. At present, that minimum appears to be 9px. Because the display name used within the apps is so long, on narrow devices the font scaling forces the font size down past the threshold, landing us here.

@jahorton
Copy link
Contributor

Without -webkit-text-size-adjust: none; applied, the WebView displays the spacebar text at a fixed 9px:

Min-thresholded font-size - is auto-forced to 9px

Note how the spacebar caption is properly scaled once the WebView's font-size thresholding behavior is disabled.

With -webkit-text-size-adjust: none; applied, and no other changes whatsoever, the WebView happily complies with our wishes and allows the font-size to go smaller - in this case, just over 7px:

Proper scaling and calculation of target font-size: just over 7px

@jahorton
Copy link
Contributor

jahorton commented Apr 11, 2024

Oh cute. Android-Chrome's WebViews do it too, locking to a minimum of 8px. ... and the threshold-disabler for Safari WebViews doesn't work there. Gonna have to do some searching to find the correct version to use there, I suppose.

And... this seems to work... for fixed-size font specifications:

https://issuetracker.google.com/issues/237374578#comment2

[...] there is a minimum font-size for WebView. Could you try either setting the minimal font size to a smaller value e.g. yourWebView.getSettings().setMinimumFontSize(1); [...]

If the font-size is relative, Android-Chrome's WebViews will still force a minimum of 8px.

@jahorton
Copy link
Contributor

jahorton commented Apr 11, 2024

... and it's not just when embedded in application WebViews. Standalone iOS Safari is subject to this as well - and it is subject to the same "fixed size" vs "relative size" behavior noted in the last comment for Android-Chrome WebViews. Interestingly, it does not require --webkit-text-size-adjust: none; styling - just a fixed-size, px-based specification.

In fact, using a fixed-size spec within a Safari WebView appears sufficient to bypass any need for --webkit-text-size-adjust.

@jahorton jahorton self-assigned this Apr 11, 2024
@jahorton jahorton changed the title bug(ios): Khmer Angkor caption name doesn't fit on the OSK's Spacebar bug(web): the in-app Khmer Angkor caption name doesn't fit on the OSK's Spacebar on mobile devices Apr 11, 2024
@keymanapp-test-bot keymanapp-test-bot bot added web/ and removed ios/ labels Apr 11, 2024
@jahorton jahorton added this to the B17S5 milestone Apr 11, 2024
@darcywong00 darcywong00 modified the milestones: B17S5, B17S6 Apr 12, 2024
@mcdurdin
Copy link
Member

I suggest we postpone this to 18.0. It's not a new issue for beta and it's purely visual aesthetic, not functional.

@jahorton
Copy link
Contributor

See also #10699; same issue, different keyboard.

@jahorton
Copy link
Contributor

jahorton commented Apr 17, 2024

Comments from #11207, which we have decided to abandon:

Agreed, I feel like this [#11207] is not addressing the actual problem, which is that there is too much text to fit on the key cap. So, we need to shorten the spacebar text, and encourage keyboard designers to avoid putting too much text on a key. Scaling to something unreadable doesn't really help anyone.

Yes, if I wasn't clear in my previous comment, I see two actions:

  1. Shorten spacebar text
  2. Encourage keyboard devs to use short keycap labels

Note that it is possible for keyboard developers to edit the language name:

(as set for khmer_angkor)

Where it is set within Developer - which is editable!

Thus, it is within reason to punt cases like this back to keyboard authors and/or to fix it ourselves for keyboards. Some keyboards (like gff_amharic) are notably more constrictive, though - Amharic's spacebar is only two standard keys wide, rather than at least 5 like sil_euro_latin and khmer_angkor!

@jahorton
Copy link
Contributor

jahorton commented Apr 17, 2024

Note: the current language-name default for km actually is "Khmer" within Developer now. All it takes is a quick edit of the tag back and forth to see this. It was probably set to this notably-longer version in a prior Developer version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

5 participants