Closed Bug 1699841 Opened 3 years ago Closed 3 years ago

[Proton] [zh-TW] Display font size too small for localized audio indicator text, leading low legibility

Categories

(Firefox :: Tabbed Browser, defect, P2)

x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
89 Branch
Tracking Status
firefox89 --- verified
firefox90 --- verified

People

(Reporter: petercpg, Assigned: jaws)

References

(Blocks 1 open bug)

Details

(Whiteboard: [proton-tabs-bar])

Attachments

(3 files)

Attached image screenshot

Steps to reproduction

  1. Enable Proton configs in about:config
  2. Load a tab with audio contents, e.g. YouTube video
  3. Observe the audio indicator text located on the tab, below page title

Expected
The text shall be easy to read, whether it's in English or localized form

Actual
In zh-TW localized version, the indicator text was too small, making it hardly legible
(Refer to screenshot)

Environment

  • Windown 10 20H2 19042.868 zh-TW
  • Nightly 88.0a1 (2021-03-19) 64-bit zh-TW
  • Screen resolution: 1920x1080 @ 100% DPI

Enabled Proton prefs

pref value
browser.proton.appmenu.enabled true
browser.proton.contextmenus.enabled true
browser.proton.doorhangers.enabled true
browser.proton.enabled true
browser.proton.places-tooltip.enabled true
browser.proton.tabs.enabled true
browser.proton.toolbar.enabled true
browser.proton.toolbar.version 3
browser.proton.urlbar.enabled true

copying Flod since this might affect other locales as well.

Whiteboard: [proton-tabs-bar]
Priority: -- → P2

Per discussion on slack with jkew:

  • the current size in Nightly is not 8pt as stated above; it's 8.25px (confirmed the computed font-size in the Inspector), which is equal to 6.1875pt. CSS pixels != points.
  • most scripts outside of Latin/Greek/Cyrillic don't have anything equivalent to "uppercase", so using ALL CAPS to achieve legibility for very small text isn't an option for those locales. A design that relies on this is inherently non-localization-friendly.
  • I tried changing the "MUTE TAB" text to Arabic, Hindi, and Chinese in my Nightly, and it is IMO uncomfortably small. On a Retina screen I can read it OK if I look closely, as the characters are reasonably crisp; but on a non-hidpi screen they become a blurry mess. Eight pixels just aren't enough to render most non-Latin scripts readably.

zh-CN alone is over 5% of our user base, we need to clarify the following now:

  • what is the minimum font size that allows our implementation of the second line of text to be readable for zh-CN, hi-IN, ja or ar (NI to jkew)
  • can we possibly increase the font size without breaking tab layout or increase tab height? How much room do we have if any? (NI to jaws)
Flags: needinfo?(jkew)
Flags: needinfo?(jaws)

As per Slack discussion, I think it's important to consult native speakers/readers about what size is acceptably readable; but to my eye, around 12px is the smallest reasonable size for zh-CN or ja; below that, on a low-res screen, the characters blur and disintegrate to the point where reading becomes as much guesswork as actual recognition. For hi-IN or ar, somewhat smaller -- perhaps 10px -- may be OK, but at 8px the characters seem very tiny and distinguishing details are getting lost.

Another somewhat related issue to watch out for is that some writing systems will really need more line height for a given font size. If elements have a fixed height that just fits English text, then a language like Hindi may see text being clipped at top and/or bottom; or conversely, if the height isn't fixed, then the automatic "normal" line height may expand when non-Latin text is present, altering the layout. For example, I see that if I put some Hindi text into the tab title with current Nightly on macOS, the label element goes from being 14px high to 19px, which spreads apart the two lines in the tab.

Flags: needinfo?(jkew)

(In reply to Romain Testard [:RT] from comment #2)

  • can we possibly increase the font size without breaking tab layout or increase tab height? How much room do we have if any? (NI to jaws)

We don't have many pixels available. I don't think we can increase it without making tabs taller. We should consider allowing locales to hide this secondary text. We can think of it as a "nice-to-have" since we didn't have it pre-Proton.

Flags: needinfo?(jaws)

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)

We don't have many pixels available. I don't think we can increase it without making tabs taller. We should consider allowing locales to hide this secondary text. We can think of it as a "nice-to-have" since we didn't have it pre-Proton.

If we do this, it should be a preference centrally stored. We know from experience that scattering this kind of information in l10n repos doesn't scale, and create more issues than it solves.

Potentially this should be available via remote-settings, so that we can fix it quicker and not wait for a full release cycle?

Is it possible to allow user to decide whether use icon or text as an option in about:preferences?

Attached image ka-tab.png

most scripts outside of Latin/Greek/Cyrillic don't have anything equivalent to "uppercase", so using ALL CAPS to achieve legibility for very small text isn't an option for those locales

Georgian has mtavruli letters, which are used for All Caps. So, I don't see any issue in ka locale.

Romain, can you please supply the list of the locales that are unsupported?

Flags: needinfo?(rtestard)

We decided to remove the second line of text for affected locales. The proposed list of locales that won't include the second line of text because of readability issues is: zh-CN, ja, ar, zh-TW, ja-JP-macos, ko, fa, he, hye, ja-JP-mac, pa-IN, th, vi

Flod thanks for taking a second look and validating the list looks right.

Flags: needinfo?(rtestard) → needinfo?(francesco.lodolo)

A few changes:

  • I think we should keep it enabled for Vietnamese. While they have a lot of decorations on some glyphs, they have uppercase and it seems readable in my test page.
  • I would add a few Indic locales that are currently not translated, just to be safe.

Looks like Jared's code looks at the first part of the locale code, so we should be able to simplify the list to just use that (zh-CN and zh-TW are covered by zh:

ar,fa,gu,he,hi,ja,km,ko,pa,ta,te,th,vi,zh

Flags: needinfo?(francesco.lodolo)

Thanks flod, let's move forward with your list!

I suspect that list should be extended to include more Arabic- and Indic-script languages; some of them don't currently show any strings on Flod's test page, but if and when the strings do get localized I'd be concerned they'll also be too small to read comfortably.

Some questionable candidates: bn, bo, ckb, gu-IN, hi-IN, km, kn, lo, mr, my, ne-NP, si, ta, te, ur. I'd expect most/all of these to be written in non-Latin scripts that will struggle to be read, although to some extent it could depend on the particular font that ends up getting used. (There could also be others that I didn't immediately recognize by their codes.)

edit: I see Flod already mentioned some of these while I was looking through the list :)

So combining suggestions and removing vi (per text in comment 11; I'm guessing it was accidentally left in) I get the list:

ar,bn,bo,ckb,fa,gu,he,hi,ja,km,kn,ko,lo,mr,my,ne,pa,si,ta,te,th,ur,zh

Are we assuming retina is sufficient for japanese to exclude the mac variant of the jp locale from the list? (I haven't checked myself on a mac)

Edit: scrap that, I missed the "Looks like Jared's code looks at the first part of the locale code"

Excluding Japanese on macOS would require a different approach/patch, and introducing checks for the full locale code. Aside from that, I'm not completely sure it's a good idea to provide different experience on different platforms for the same locale (it's already confusing that we do for different locales).

@jaws
The list in comment 14 covers all the locales, I'd go with that (I excluded some because they're not very active, but on second thoughts it doesn't make a lot of sense).

Great, thanks! I'll update the patch now.

Assignee: nobody → jaws
Status: NEW → ASSIGNED

@flod: Clarification, I thought the list did not include japanese on mac, but then saw the comment about only the first part of the locale being matched, so that "ja" covers "ja-*"

Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1c2dd3cf99f9
Hide the secondary text for locales where it doesn't fit, and always make the overlay icon visible in such locales. r=desktop-theme-reviewers,harry
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Verified as fixed on Windows 10 x64, macOS 10.15, Ubuntu 20.04 and on Windows 7 x64.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: