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

Automatic hyphenation doesn’t work in Chrome Android, ChromeOS, Linux, and Windows #31

Closed
JayPanoz opened this Issue Feb 17, 2018 · 20 comments

Comments

Projects
None yet
4 participants
@JayPanoz
Collaborator

JayPanoz commented Feb 17, 2018

While I can get hyphens: auto to work in Chrome Desktop, we just can’t get it to work in Chrome Mobile (including Web Views).

Here’s what you can get on Desktop:

chrome-desktop

On mobile, it just won’t happen…

screenshot_2018-02-17-18-03-53

Even in landscape…

screenshot_2018-02-17-18-04-24

Tried changing the lang attribute from en to en-US to check if their mapping is super strict, to no effect.

Checked other ebook apps, and got the same result: no hyphens.

It kinda drives me crazy as it is supposed to be supported in Chrome only on Android and Mac…

Links:

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 17, 2018

So yeah, it seems it doesn’t work in Android.

The only manual test they’ve made is checking this link from a bug report to make sure it doesn’t crash Chrome Mobile…

And here’s what I could get:

screenshot_2018-02-17-18-59-16

On a related note, hyphens aren’t implemented on Windows, Linux ChromeOS yet.

So, question: do we want to just remove the setting from the non-iOS apps until they fix those issues?

We manage that automatically when the text-align is set so should those issues be fixed, we’ll at least have that automatic handling.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 18, 2018

Bug reported. Here is the related Chromium issue.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

Hyphen dicts available in Android 6.0.1 are:

  • English American (en-US)
  • Basque (eu)
  • Hungarian (hu)
  • Armenian (hy)
  • Norwegian Bokmal (nb)
  • Norwegian Nynorsk (nn)
  • Sanskrit (sa)
  • Pan Ethiopian (und-ethi)

They’re available in system/usr/hyphen-data (and accessible with apps such as ES File Explorer). It would be a good idea to list the dicts available for each version.

@laudrain

This comment has been minimized.

laudrain commented Feb 20, 2018

Nothing for French !

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

Yeah, cc-ing @HadrienGardeur since we talked about that a few months ago and wondered whether we should embed ours.

But if we can’t get Chrome to hyphenate in the first place…

@JayPanoz

This comment has been minimized.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

Given this issue impacts Electron as well on non-MacOS platforms, we’d better discuss it during the next call. cc @llemeurfr

Adding support would mean polyfilling this e.g. Hyphenator.js

@llemeurfr

This comment has been minimized.

Contributor

llemeurfr commented Feb 20, 2018

So if I try to summarize, hyphenation support by a rendering engine depends on the platform, the language (dict or no dict). Polyfilling is doable, but the system should be smart enough to avoid loading the js if hyphenation is natively supported.

I'll add that dyslexic user can't read with hyphenation on, therefore disabling hyphenation should be a user setting (advanced) and it should be disabled on some of the themes we'll provide.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

So yes, in anticipation of the call, a recap:

  1. No support at all
    • hyphenation isn’t enabled at all;
    • you’ll end with huge gaps between words if the author/user justifies text.
  2. Partial support
    • only the values none and manual are supported;
    • manual is what polyfills leverage, by inserting the ­ character (soft-hyphen, which is invisible) all over the place, in every word applicable;
    • this is Chrome on Windows, Linux, and ChromeOS.
  3. Complete support
    • the value auto is supported in addition to none and manual;
    • quality depends on dictionaries available on the platform;
    • if a dict is not available, rendering engine may either fall back to english dict or complete disabling.

I know of early experiments to insert ­ characters in EPUB files to make it work anywhere but this can’t really scale well in production so they were short-lived. Now, it means that if authors justify text, we’ll have large gaps between words which, as you mentioned, hurts a11y. That should be solved by aligning text left though.

The biggest issue is an UX one i.e. having a setting which does nothing because automatic hyphenation is not supported.

Reference: canIuse

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

Also, after taking a quick look at hyphenator.js issues, I’d rather not recommend polyfilling it whenever possible, as it might create extra issues e.g. performance issues (all words have to be checked in the DOM and modified when a pattern is applicable) and a11y issues (screen readers have a hard time managing soft hyphens).

On a related note, implementers willing to support hyphenation in MS browsers will probably have to check stylesheets for -ms-hyphens and add it if it can’t be found (same issue as vertical writing i.e. filling the gaps for bad authoring practices).

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 20, 2018

So the current version of Android embeds hyphenation dicts for…

  • Assamese (as)
  • Bulgarian (bg)
  • Bengali (bn)
  • Church Slavonic (cu)
  • Welsh (cy)
  • Danish (da)
  • German (de)
  • UK English (en-GB)
  • American English (en-US)
  • Spanish (es)
  • Estonian (et)
  • Pan-Ethiopic (und-ethi)
  • Basque (eu)
  • French (fr)
  • Irish (ga)
  • Gujarati (gu)
  • Hindi (hi)
  • Croatian (hr)
  • Hungarian (hu)
  • Armenian (hy)
  • Kannada (kn)
  • Malayalam (ml)
  • Mongolian in the Cyrillic script (mn-Cyrl)
  • Marathi (mr)
  • Norwegian Bokmal (nb)
  • Norwegian Nynorsk (nn)
  • Oriya (or)
  • Panjabi (pa)
  • Portuguese (pt)
  • Sanskrit (sa)
  • Slovenian (sl)
  • Tamil (ta)
  • Telugu (te)
  • Turkmen (tk)

All seems to be retrieved from TeX (LaTeX patterns, hyphenation.org).

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 21, 2018

So, the good news is that a fix is on its way for Chrome Android: https://chromium-review.googlesource.com/c/chromium/src/+/927931

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 22, 2018

As a recap of our discussion about the global issue during yesterday’s call…

  • We can’t embed hyphenation dictionaries easily, since @hyphenate-resource has been removed from the CSS Text specification and was only implemented by an HTML2Print software
  • We therefore have to rely on system dictionaries so, on Android, it means the user almost have to change its device to get more dictionaries (because system updates…)
  • Polyfilling via JS is too costly, and is likely to create dev complications, performance, and accessibility issues (some screen readers cut the word where the soft-hyphen is and one word may become two or three)
  • We consequently have to rely on browsers because both options are non-starters
  • We will lobby for hyphens and dictionaries but can’t realistically do much more

There’s hope though, as the Chrome Android issue has been tackled within 24 hours, is currently being patched, helped discover other issues and even improve i18n hyphenation – it also proves one tiny R2 demo can go a loooong way.

So as soon as Chromium is able to fix the Windows issue (they’re relying on Microsoft it seems), things could go pretty fast.

@JayPanoz JayPanoz changed the title from Hyphenation doesn’t work in Chrome Mobile to Automatic hyphenation doesn’t work in Chrome Android, ChromeOS, Linux, and Windows Feb 22, 2018

@JayPanoz JayPanoz added the Discussion label Feb 26, 2018

JayPanoz added a commit that referenced this issue Feb 26, 2018

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Feb 26, 2018

This has been documented in the alpha version and will be closed as soon as the Chromium bug referenced in the third message is.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Apr 16, 2018

Update: waiting for an Android 8.0 device (stock Oreo), which should be delivered this week, to confirm Chromium’s fix works because it currently doesn’t on an Android 6.0.1 device.

@HadrienGardeur

This comment has been minimized.

HadrienGardeur commented Apr 16, 2018

I'm running 8.1, is there anything that I can easily test?

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Apr 16, 2018

Ah yes, that would help, thanks. The test can simply be r2-glue-js demo page in Chrome Canary (which is available on the App Store if you don’t have it already), they’ve been using it on their side to test the patch.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Apr 16, 2018

So Hadrien could confirm the patch works, although word-spacing management is quite liberal.

screenshot_20180416-164030

screenshot_20180416-164037

It would be nice if people could post on the Chromium issue if they think this is too liberal. I’ll post an update there.

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Apr 16, 2018

As a proposed resolution at the Readium-CSS level, we should probably advise against putting an hyphen-specific user setting in the UI.

Further details:

  • we’re already managing hyphenation through text-align so it should not create an a11y issue since picking left in user settings will disable hyphenation automatically – even manual;
  • besides, there are languages for which dictionaries are not available anyway and there’s no way we can check that so we’re kinda getting around this issue by doing so;
  • Chrome (hence Electron) on Windows is totally dependent on Microsoft releasing a public API so there’s probably some lobbying to do.

Which means I’ll have to make some doc changes before closing #37.

@JayPanoz JayPanoz referenced this issue Apr 16, 2018

Merged

Alpha release #37

@JayPanoz JayPanoz modified the milestone: beta release Apr 16, 2018

JayPanoz added a commit that referenced this issue Apr 16, 2018

@JayPanoz

This comment has been minimized.

Collaborator

JayPanoz commented Apr 25, 2018

So this is pretty much out of our hands now. We can close this issue since Chromium fixed it.

Since hyphenation is the responsibility of browsers/rendering engines, please raise other hyphenation-related issues in their dedicated issue tracker:

Thanks in advance.

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