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)
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?
Comment 1•12 years ago
|
||
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
Comment 2•12 years ago
|
||
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.
Reporter | ||
Updated•12 years ago
|
Component: General → Reader Mode
Reporter | ||
Comment 3•12 years ago
|
||
Alex, what sort of testing would you recommend to ensure we're doing the right thing in Reader Mode, l10n-wise?
Reporter | ||
Updated•12 years ago
|
Priority: -- → P2
Comment 4•12 years ago
|
||
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.
Reporter | ||
Comment 5•12 years ago
|
||
(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, ...).
Reporter | ||
Comment 6•12 years ago
|
||
Nothing actionable has come from this bug for some time now. Closing.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•