Closed Bug 766623 Opened 12 years ago Closed 12 years ago

Reader Mode: Ensure Reader Mode is i18n-friendly

Categories

(Firefox for Android Graveyard :: Reader View, defect, P2)

All
Android
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: lucasr, Unassigned)

References

Details

The current Reader Mode design involves the use of custom fonts. We're starting off by using Open Sans which doesn't support a wide range of glyphs. We'll have to balance the design direction with the i18n requirements. There's platform work being done to allow downloading fonts on demand for the languages not supported by the system fonts (see bug 619521). Maybe this is something we should integrated in the reader somehow?
Reader mode design: https://wiki.mozilla.org/Fennec/NativeUI/UserExperience/ReaderMode It would be a pretty sucky UX to invoke reader for the first time and see a lot of little blocks or question marks while a font was downloaded - or just have a blank screen. We need to minimise the likelihood of that. I see two ways: 1) Allow localized builds of Firefox to bundle a font which has glyphs for their region's commonly-used alphabets. 2) Fall back instantaneously, or at least until the download is finished, to system fonts. Whatever happens, input from the UX team is needed in defining the fonts supplied. I am told that the B2G UX team are currently commissioning a new font to give B2G a distinctive look. That font will need a wide range of glyphs. I see potential for coordination here. Lucas: do you want to send out some enquiries and see who is handling that? Gerv
As this is "script support in content", doing stuff on the l10n side won't help much. If I look at a Japanese text, it should look right, independent of the fact that I can't read it ;-). This is similar to hyphenation dicts, which we're shipping independently of the locale.
Component: General → Reader Mode
Alex, what sort of testing would you recommend to ensure we're doing the right thing in Reader Mode, l10n-wise?
Priority: -- → P2
Is there documentation on which scripts and alphabets the font supports? Also, it'd be good to review what happens visually when the font fails. http://www.mozilla.org/vi/firefox/channel/ is my pet example of a individual glyphs falling back to a different font within a word, due to unsupported alphabets.
(In reply to Axel Hecht [:Pike] from comment #4) > Is there documentation on which scripts and alphabets the font supports? See Character Map section here: http://www.fontsquirrel.com/fonts/open-sans > Also, it'd be good to review what happens visually when the font fails. > http://www.mozilla.org/vi/firefox/channel/ is my pet example of a individual > glyphs falling back to a different font within a word, due to unsupported > alphabets. Reader seems to be doing fine in that page. I also tested the same page in several languages (no, pl, es, pt, se, de, ...).
Nothing actionable has come from this bug for some time now. Closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.