Font stacks for Default styles (and UI) about readium-css HOT 36 CLOSED

More importantly, preference is an important factor

Here is the main point ! If you want to improve reading ability, you must empower the user. Trust in the user's choice. Make the choice easier for them.

from readium-css.

Not sure if this could be the ultimate list of default font-stacks but it comes pretty close to it at first sight.

The font-stacks cover:

• MacOS > 10.9
• iOS > 9
• Windows > 7
• Android > 4.4.4

Unicode ranges are specifically scoped to their language and are provided in case you want to use other typefaces: it can help you check support, coverage and subset if needed.

UI

font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, Noto, Oxygen-Sans, Ubuntu, Cantrell, "Helvetica Neue", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol";

Latin

Old Style (serif)

font-family: "Iowan Old Style", "Sitka Text", Palatino, "Book Antiqua", serif;

Modern (serif)

font-family: Athelas, Constantia, Georgia, serif;

Neutral (sans)

Same as UI font-stack or the following simplified version:

font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, Noto, "Helvetica Neue", Arial, sans-serif;

Humanist (sans)

font-family: Seravek, Calibri, Roboto, Arial, sans-serif;

Monospace

font-family: "Andale Mono", Consolas, monospace;

Unicode ranges

Unicode ranges are:

/* Basic Latin */
unicode-range: U+0020-007F;

/* Latin 1 supplement */
unicode-range: U+0080-00FF;

/* Latin extended A */
unicode-range: U+0100-017F;

/* Latin extended B */
unicode-range: U+0180-024F;

In addition, you might want to cover Greek and Cyrillic.

/* Greek and coptic */
unicode-range: U+0370-03FF;

/* Cyrillic */
unicode-range: U+0400-04FF;

/* Cyrillic Supplement */
unicode-range: U+0500-052F;

Amharic (am)

font-family: Kefa, Nyala, Roboto, Noto, "Noto Sans Ethiopic", serif;

Warning: no iOS.

unicode-range: U+1200-137F, U+1380-139F;

Arabic (ar)

font-family: "Geeza Pro", "Arabic Typesetting", Roboto, Noto, "Noto Naskh Arabic", "Times New Roman", serif;

unicode-range: U+0600-06FF, U+0750-077F, U+08A0-08FF;

Bengali/Bangla (bn)

font-family: "Kohinoor Bangla", "Bangla Sangam MN", Vrinda, Roboto, Noto, "Noto Sans Bengali", sans-serif;

unicode-range: U+0980-09FF;

Tibetan (bo)

font-family: Kailasa, "Microsoft Himalaya", Roboto, Noto, "Noto Sans Tibetan", sans-serif;

unicode-range: U+0F00-0FFF;

Cherokee (chr)

font-family: "Plantagenet Cherokee", Roboto, Noto, "Noto Sans Cherokee";

Warning: no iOS.

unicode-range: U+13A0-13FF;

Persian (fa)

font-family "Geeza Pro", "Arabic Typesetting", Roboto, Noto, "Noto Naskh Arabic", "Times New Roman", serif;

unicode-range: U+0600-06FF, U+0750-077F, U+08A0-08FF;

Gujarati (gu)

font-family: "Gujarati Sangam MN", "Nirmala UI", Shruti, Roboto, Noto, "Noto Sans Gujarati", sans-serif;

unicode-range: U+0A80-0AFF;

Hebrew (he)

font-family: "New Peninim MT", "Arial Hebrew", Gisha, "Times New Roman", Roboto, Noto, "Noto Sans Hebrew" sans-serif;

unicode-range: U+0590-05FF;

Hindi (hi)

font-family: "Kohinoor Devanagari", "Devanagari Sangam MN", Kokila, "Nirmala UI", Roboto, Noto, "Noto Sans Devanagari", sans-serif;

unicode-range: U+0900-097F, U+A8E0-A8FF;

Armenian (hy)

font-family: Mshtakan, Sylfaen, Roboto, Noto, "Noto Serif Armenian", serif;

Warning: no iOS.

unicode-range: U+0530-058F;

Inuktitut (iu)

font-family: "Euphemia UCAS", Euphemia, Roboto, Noto, "Noto Sans Canadian Aboriginal", sans-serif;

unicode-range: U+1400-167F;

Japanese (ja)

font-family: "游ゴシック体", YuGothic, "ヒラギノ丸ゴ", "Hiragino Sans", "Yu Gothic UI", "Meiryo UI", "MS Gothic", Roboto, Noto, "Noto Sans CJK JP", sans-serif;

unicode-range: U+3000-303F, U+3040-309F, U+30A0-30FF, U+FF00-FFEF, U+4E00-9FAF;

Khmer (km)

font-family: "Khmer Sangam MN", "Leelawadee UI", "Khmer UI", Roboto, Noto, "Noto Sans Khmer", sans-serif;

unicode-range: U+1780-17FF, U+19E0-19FF;

Kannada (kn)

font-family: "Kannada Sangam MN", "Nirmala UI", Tunga, Roboto, Noto, "Noto Sans Kannada", sans-serif;

unicode-range: U+0C80-0CFF;

Korean (ko)

font-family: "Nanum Gothic", "Apple SD Gothic Neo", "Malgun Gothic", Roboto, Noto, "Noto Sans CJK KR", sans-serif;

unicode-range: U+1100-11FF, U+3130-318F, U+A960-A97F, U+AC00-D7AF, U+D7B0-D7FF;

Lao (lo)

font-family: "Lao Sangam MN", "Leelawadee UI", "Lao UI", Roboto, Noto, "Noto Sans Lao", sans-serif;

unicode-range: U+0E80-0EFF;

Malayalam (ml)

font-family: "Malayalam Sangam MN", "Nirmala UI", Kartika, Roboto, Noto, "Noto Sans Malayalam", sans-serif;

unicode-range: U+0D00-0D7F;

Oriya (or)

font-family: "Oriya Sangam MN", "Nirmala UI", Kalinga, Roboto, Noto, "Noto Sans Oriya", sans-serif;

unicode-range: U+0B00-0B7F;

Punjabi (pa)

font-family: "Gurmukhi MN", "Nirmala UI", Kartika, Roboto, Noto, "Noto Sans Gurmukhi", sans-serif;

unicode-range: U+0A00-0A7F;

Sinhalese (si)

font-family: "Sinhala Sangam MN", "Nirmala UI", "Iskoola Pota", Roboto, Noto, "Noto Sans Sinhala", sans-serif;

unicode-range: U+0D80-0DFF;

Tamil (ta)

font-family: "Tamil Sangam MN", "Nirmala UI", Latha, Roboto, Noto, "Noto Sans Tamil", sans-serif;

unicode-range: U+0B80-0BFF;

Telugu (te)

font-family: "Kohinoor Telugu", "Telugu Sangam MN", "Nirmala UI", Gautami, Roboto, Noto, "Noto Sans Telugu", sans-serif;

unicode-range: U+0C00-0C7F;

Thai (th)

font-family: "Thonburi", "Leelawadee UI", "Cordia New", Roboto, Noto, "Noto Sans Thai", sans-serif;

unicode-range: U+0E00-0E7F;

Chinese (zh-CN)

font-family: "方体", "PingFang SC", "黑体", "Heiti SC", "Microsoft JhengHei UI", "Microsoft JhengHei", Roboto, Noto, "Noto Sans CJK SC", sans-serif;

unicode-range: U+3000-303F, U+3040-309F, U+30A0-30FF, U+FF00-FFEF, U+4E00-9FAF;

Chinese – Hong Kong (zh-HK)

font-family: "方體", "PingFang HK", "方體", "PingFang TC", "黑體", "Heiti TC", "Microsoft JhengHei UI", "Microsoft JhengHei", Roboto, Noto, "Noto Sans CJK TC", sans-serif;

Chinese – Taiwan (zh-TW)

font-family: "方體", "PingFang TC", "黑體", "Heiti TC", "Microsoft JhengHei UI", "Microsoft JhengHei", Roboto, Noto, "Noto Sans CJK TC", sans-serif;

Please feel free to review those font-stacks and improve them if needed.

from readium-css.

A quick update to list open source alternatives for some typefaces in our default stacks. This list will come in handy for Android (since it only ships with Droid fonts) but could also serve as a reference if you don’t want to use system fonts on iOS/Windows.

• Seravek → Source Sans Pro
• Athelas → Cardo (it’s missing a bold italic style though)
• Iowan Old Style → Crimson Text

In addition, here’s a list of alternatives for popular typefaces you might add to the default stacks:

• Bookman → Vollkorn
• Charter → Charis SIL
• Franklin Gothic → Libre Franklin
• Georgia → Droid Serif
• Optima → URW Classico
• Times → Tinos
• Univers → Free Universal
• Verdana → PT Sans

I’ve been trying to pick the better-rendering fonts with the best languages support and most styles available for each alternative but some typefaces (e.g. Free Universal) might not provide support for non-latin languages. So please keep that in mind when making your fonts selection.

from readium-css.

Typefaces for dyslexia

I’ll need a review before adding this part to the docs.

This is a tricky topic, and it needs quite some expertise, so those won’t be recommendations per se but mere insights, since extended research is currently being done in this field. As a consequence, implementers willing to provide the best experience possible should try to keep up-to-date.

Typefaces don’t work in a vacuum

From research conducted by Charles Bigelow – who designed Lucida and Wingdings with Kris Holmes –, on a corpus of existing scientific research and books:

In the scientific literature, I found no evidence that special dyslexia fonts confer statistically significant improvements in reading speed compared to standard, run-of-the-mill fonts. Some studies found that for certain subsets of reading errors, special dyslexia fonts do reduce error rates for dyslexic readers, yet for other subsets of errors, special dyslexic fonts were no better, or in some cases worse; hence, the findings on reading errors are mixed.

Typography is indeed a system and other factors have to be taken into account:

[…] the sizing, spacing, and arrangement of type, but not typeface design per se – a few scientific papers found that certain variations in typography offer statistically significant benefits to dyslexic readers.

If needed, the sources of papers and studies available online at the time of this research are listed in this companion article.

General tips

It is important to emphasize that the user settings (and their values) implementers will offer users is as equally – if not more – important as the typefaces themselves.

A list of general tips:

• avoid justified text (text-align setting);
• use generous line spacing / leading (line-height setting);
• use generous letter spacing (letter-spacing setting);
• avoid italics;
• generally use sans serif faces (font-family setting);
• use larger text (font-size setting);
• use good contrast (background- and color settings, reading modes, themes);
• use clear, concise writing.

The WCAG 2.1 spec, especially the “Adapting text” section, can serve as a starting point to choose the values you might at least offer to users for those settings.

We’ve been trying to define a baseline for a11y-related user settings, and you’ll find further information and extra features you might want to implement in issue #18 (alternated colors for lines of text or words, etc.).

On typefaces themselves

Although typefaces specifically designed for dyslexia exist, users might prefer system fonts they are used to. The following system typefaces are almost always listed as good for dyslexia:

• Arial/Helvetica
• Trebuchet MS
• Verdana

Those fonts are available on both Windows and MacOS/iOS so it would be a good idea to have at least 2 of them available in the typeface user setting.

More importantly, preference is an important factor, and implementers might want to give access to user-installed fonts if the platform allows. When doing research, some participants indeed emphasized they installed a specific font for dyslexia, and they want to be able to use it in the reading app as well.

Conclusion

It’s not just about fonts, it’s about typography and user-settings allowing its customization.

At the very minimum, you might want to provide:

• 2–3 system fonts listed as good for dyslexia;
• a font specifically designed for dyslexia;
• a reliable font-size setting (i.e. that will work for all reflowable EPUB files);
• a line-height setting;
• a text-align setting;
• a letter-spacing setting.

It is noteworthy that everything extra will have to be implemented with great care: too many settings might create a cognitive overload for some users, so UX research should be conducted accordingly.

from readium-css.

OK so for latin, here’s what I can reasonably recommend:

Order is

Apple, Microsoft, Android, web safe, generic family

For default local fonts (generic family), check fontfamily.io

Oldstyle (serif)

font-family: "Iowan Old Style", "Sitka Text", Palatino, "Book Antiqua", serif;

Serif will resolve to Droid Serif on Android.

Modern (serif)

font-family: Athelas, Constantia, Georgia, serif;

Serif will resolve to Droid Serif on Android.

Neutral (sans)

font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

Humanist (sans)

font-family: Seravek, Calibri, Roboto, Arial, sans-serif;

Sans-serif will resolve to Droid Sans or Roboto on Android.

Monospace

font-family: "Andale Mono", Consolas, monospace;

Monospace will resolve to Droid Sans Mono on Android.

Apple is shipping a monospaced San Fransisco in High Sierra but it is still unclear how you can access it in CSS.

from readium-css.

Will need help for the following, related to CJK/RTL.

Targets:

• MacOS 10.9 / iOS 9
• Windows 7
• Android 4.4.4

Japanese

Have found font-stacks for Japanese but I’m pretty sure we can get rid of a lot of typefaces in there. At first sight, they can be used for both traditional and simplified.

Default

【horizontal writing, Mincho】font-family: serif-ja, serif;
【vertical writing, Mincho】font-family: serif-ja-v, serif-ja, serif;
【horizontal writing, gothic】font-family: sans-serif-ja, sans-serif;
【vertical writing, gothic】font-family: sans-serif-ja-v, sansserif-ja, sans-serif;

Gothic (sans-serif)

font-family: "HiraKakuPro-W3", "Hiragino Kaku Gothic Pro W3", "Hiragino Kaku Gothic Pro", "ヒラギノ角ゴ Pro W3", "メイリオ", Meiryo, "游ゴシック", YuGothic, "ＭＳ Ｐゴシック", "MS PGothic", "ＭＳ ゴシック", "MS Gothic", sans-serif;

Mincho (serif)

font-family: "HiraMinPro-W3", "Hiragino Mincho Pro W3", "Hiragino Mincho Pro", "ヒラギノ明朝 Pro W3", "游明朝", YuMincho, "HG明朝E", "ＭＳ Ｐ明朝", "MS PMincho", "MS 明朝", "MS Mincho", serif

Chinese

Had to make my owns, and it’s super difficult when you don’t speak Mandarin. At first sight, they can be used for both traditional and simplified.

(Apologies if it’s not “Gothic/Mincho”, this is what I’ve found on Wikipedia.)

Gothic (sans-serif)

font-family: "PingFang SC", "儷黑 Pro", "LiHei Pro", "Microsoft JhengHei", sans-serif;

Mincho (serif)

font-family: "儷宋 Pro", "LiSong Pro", "PMingLiU", "MingLiU", serif;

Korean

TBD

Arabic

Once again, had to make my own.

font-family: "Al Nile", "Arabic Typesetting", sans-serif;

Hebrew

Had to make my own as well.

font-family: "Arial Hebrew", "Arial Unicode MS", Arial, sans-serif;

And of course, there are other languages I’ll have to deal with so they’re missing at the moment. Sorry.

from readium-css.

Another solution for CJK/RTL is obviously Noto but performance, especially when the font file is 15mb (Unicode-range could be a trick up our sleeve though).

from readium-css.

FYI, those are the fonts Apple is offering in iBooks.

Latin

• Athelas
• Charter
• Georgia
• Iowan Old Style
• Palatino
• San Francisco
• Seravek
• Times New Roman

Amharic (am)

• Kefa

Arabic (ar)

• Damascus
• Decotype Naskh
• Al Bayan
• Kufi Standard GK
• Nadeem
• Geeza Pro
• Times New Roman

Bengali/Bangla (bn)

• Bangla MN
• Bangla Sangam MN

Tibetan (bo)

• Kokonor
• Kailasa

Cherokee (chr)

• Plantagenate Cherokee

Gujarati (gu)

• Gujarati MT
• Gujarati Sangam MN

Hebrew (he)

• New Peninim MT
• Corsiva Hebrew
• Raanana
• Arial Hebrew
• Times New Roman

Hindi (hi)

• Devanagari MT
• Devanagari Sangam MN

Armenian (hy)

• Mshtakan

Inuktitut (iu)

• Euphemia UCAS

Japanese (ja)

• 游ゴシック体 (Yu Gothic)
• 游明朝体 (Yu Mincho)
• ヒラギノ角ゴ (Hiragino Kaku Gothic ProN)
• ヒラギノ明朝 (Hiragino Mincho ProN)
• ヒラギノ丸ゴ (Hiragino Maru Gothic ProN)

Khmer (km)

• Khmer MN
• Khmer Sangam MN

Kannada (kn)

• Kannada MN
• Kannada Sangam MN

Korean (ko)

• Hiragino Sans Korean
• Seoul Gothic
• Seoul Myungjo
• Apple SD Gothic Neo
• NanumGothic
• NanumMyeongjo

Lao (lo)

• Lao MN
• Lao Sangam MN

Malayalam (ml)

• Malayalam MN
• Malayalam Sangam MN

Oriya (or)

• Oriya MN
• Oriya Sangam MN

Punjabi (pa)

• Gurmukhi MT
• Gurmukhi MN

Sinhalese (si)

• Sinhala MN
• Sinhala Sangam MN

Tamil (ta)

• Tamil MN
• InaiMathi
• Tamil Sangam MN

Telugu (te)

• Telugu MN
• Telugu Sangam MN

Thai (th)

• Ayuthaya
• Krungthep
• Sathu
• Silom
• Thonburi

Chinese (zh-cn)

• 方体 (PingFang SC)
• 黑体 (Heiti SC)
• 宋体 (Songti SC)
• 楷体 (Kaiti SC)
• 圆体 (Yuanti SC)

Chinese — Hong Kong (zh-hk)

• 方體 (PingFang HK)
• 黑體 (Heiti TC)
• 宋體 (Songti TC)
• 楷體 (Kaiti TC)
• 圓體 (Yuanti TC)

Chinese - Taiwan (zh-tw)

• 方體 (PingFang TC)
• 黑體 (Heiti TC)
• 宋體 (Songti TC)
• 楷體 (Kaiti TC)
• 圓體 (Yuanti TC)

from readium-css.

It seems that Google Fonts is experimenting with unicode-range to slice CJK fonts, cf. https://fonts.google.com/earlyaccess#Noto+Sans+SC+Sliced.

As far as I can tell, it implies the page should be reachable (but in case it is not, we would still have default fallbacks).

Using this method, the entire web page will seem to be using Noto Sans SC while only loading the set of font slices required for that page, which we expect to be much faster than loading the whole font. Cross-site caching is a key benefit of using the Google Fonts API, and since each slice of this font can be used across websites, the latency benefits increase over time.

Any way we can benefit from it or is it a non-starter?

from readium-css.

I’ve just came across Accessible-DfA, which is a a11y-centric font designed by Orange and could be used as a replacement to Open Dyslexic—and it supports Math and a lot of diacritics.

@laudrain Do you think this font could be an alternative to Open Dyslexic? It is my understanding that it was not only designed for dyslexia and covers other needs.

from readium-css.

Do you allow me to share this question with Mobidys ? They are deeply involved in EPUB for dyslexic people.

from readium-css.

Of course, sure. If that can help, it’s in use on this webpage.

from readium-css.

Done.

from readium-css.

Thanks!

from readium-css.

@laudrain Did you get any feedback regarding Accessible-DfA?

We’ll have to add a dys typeface soon and it would help knowing which one we’ll use at the CSS design level.

from readium-css.

I did investigate with DYS application developers and they answered that no font is perfect.
I think Open Dyslexic is more universally used like in Kobo eInk readers, and perhaps more open than the Orange one.

from readium-css.

OK thanks!

We indeed planned to have a minimal list of recommended typefaces (system and libre fonts) because of this.

And you’re right when taking global use into account. This is one major point to factor in.

FWIW, I checked available glyphs this morning (it is indeed one of the main issues reported for OpenDyslexic):

• OpenDyslexic lacks some diacritics (some being heavily used in eastern-european languages) but supports basic greek;
• Accessible-dfa has more diacritics (and extended glyphs), supports Math but doesn’t support greek.

So they’re more complementary than interchangeable as a matter of fact.

from readium-css.

On a related note, should we use OpenDyslexic and have issues reported about language support, etc., they use a bounty program to back issues.

I know this is really tricky since it’s about your budgets, but what would be the possibility to do such bounties, @llemeurfr? I’m not holding my breath, maybe this outscopes the mission of EDRLab by far.

from readium-css.

Our mission is to ease digital reading, by fostering the adoption of EPUB 3+ and accessibility best practices and help developing related open-source software. Therefore proposing a bounty is possible. But the list of international characters which are missing in Open Dyslexic is impressive. Why Cyrillic and not Bengali? And it seems that very few people propose bounties there and few people take these bounties.

from readium-css.

Oh yeah this is definitely one of those “going-down-the-rabbit-hole-process” and balancing priorities, bounties, etc. can become complex at some point, should bounties work in the first place (as you mentioned).

To be honest, I don’t think EDRLab should be the only one investing in bounties there. Indeed, type design is quite a heavy work.

Having filled the gaps for accentuated characters on some occasions, I know you can get it look OK-ish by combining diacritics + non-accentuated characters, but it takes the trained eye of a type designer to get it perfect as there is a lot of optical adjustments to do. Then you have to check rendering, kern pairs, do hinting, etc.

To sum things up, that’s a lot of hours spent on a few characters and I’m afraid “interesting” bounties won’t come cheap. E.g. you can probably add 2 zeros at the end of the current bounty for cyrillic to illustrate “interesting bounty for type design”, which is why the “tricky” in my previous message. So this should be more of a collective/partnership effort in the first place imho, it would be quite insane to ask you doing it on your single own, especially for one typeface which is missing so much characters.

Hmm hmm, let me think about something other options. Just recording my thoughts there, nothing more, nothing less.

• I know Titillium was created and is being maintained by a school in Italy for instance, but it could be even trickier to find partnerships to do that: to begin with, it’s someone else’s project; and it’s a dyslexic font, which requires some research beforehand;
• I know CNAP (Ministère de la culture et de la communication) has commissioned Infini two years ago but don’t know if this was a one-shot or if they could be interested in this;
• I know Orange has been putting a lot of efforts into accessibility lately (cf. https://github.com/Orange-OpenSource/Orange-Confort-plus and their typeface) but I guess it could be more interesting to @Lucmaumet (global level) than this dyslexic typeface discussion.

It is my understanding that this will likely require tremendous efforts and, although I believe this discussion can be useful, it’s probably a little bit too early. So yeah, let’s wait for Luc’s report, we’ll see things more clearly then.

from readium-css.

I've got a more substantial answer from MOBIDYS about Accessible-DfA (sorry it's in French):
"Toutefois, à l’étude de DFA, j’observe que la simplification proposée correspondrait sans doute aux maximum de critères sollicités par les différentes pathologies.
Par ailleurs, elle est moins stigmatisante que Opendys, et s’apparente aux autres corpus de police de nos traitements de texte.
Pour toutes ces raisons, je conclurai favorablement à l’utilisation de DFA plutôt que de Opendys."

To sum up, they prefer Accessible-DfA to OpenDys.

from readium-css.

Ah pretty interesting, thanks.

What’s noteworthy to our non-french-speaking friends:

• accessible-dfa meets requirements for more diverse conditions (it seems to be one of their key design point btw);
• it is less stigmatizing than OpenDyslexic;
• it shares similarities with typefaces we use in word processors;
• for all of those reasons, it can be considered a strong alternative to Open Dyslexic.

Then the major issue is language support. Both are missing a lot of characters so I guess we’ll have to find creative solutions there.

Once again, it’s worth repeating (as Luc Audrain already said above) that those typefaces are not silver bullets, they’re just “another option” and it’s a lot better to provide the user with an extended selection of typefaces.

from readium-css.

Since we felt we reached some kind of consensus there, we decided to implement Accessible Dfa in the iOS test app. It is not implemented in the prototype on the develop branch yet, as it will probably be better to collect some feedback first, and see if users don’t prefer Open Dyslexic.

On a related note:

• Open Dyslexic has more styles (normal, italic, bold, bold italic);
• It offers an alternate (Alta);
• It provides a monospace version (which we could use for code for instance);
• There’s more activity on this repo (AccessibleDfa was last updated 3 months ago and there is no visible plan related to development of language support/extended charsets)

So add those to the list of things implementers should take into account. We have the luxury to test Accessible Dfa but that might not be the case for others.

from readium-css.

More generally, I’m also running 2 forms so that we collect some data on readers’ preferred typefaces. That may be a good starting point for libre fonts we should recommend for themes.

I must unfortunately run them in several languages as there is a cultural factor to weigh in, and some languages will obviously have super specific fonts (cf. the list above).

Here you go for the english one: https://goo.gl/forms/rgx6Hg3CkX2vl2nT2

And the french one: https://goo.gl/forms/eXtxnQ8OCmHOEmxT2

Should we want to do such for CJK, arabic, hindi languages, etc., I guess it would be easier to have those forms localized, and run by people who can understand those languages.

As an interesting note, since this data is anonymized, I’ll be able to export and provide CSV files in docs.

[edit] And one of the super early findings: we’re missing a slab serif (e.g. Caecilia-like), it’s pretty popular it seems.

from readium-css.

Following up on my previous comment, the forms have been running for a while now and I am confident we can list some insights. I may edit it at some point if needed.

I won’t be taking answers at face value since they can be biased – given the eprdctn and a11y communities on Twitter, and the probable tech-savyness of people who came across those forms in the first place; what is the most interesting to me is the open-ended questions so this is an interpretation and maybe others could have a different one (please tell me if you want anonymized results).

People change the publisher’s typeface

That would not be a surprise to any implementer I believe, but I prefer listing this so that CSS authors know that.

At least in those two forms, people keeping the publisher’s typeface are in the minority (< 15%). If you’re an implementer having data related to this, feel free to share it.

To clarify, it means that people at least change the typeface occasionally (see reasons below), they don’t necessarily do it for each ebook – and that can be explained by the fact some ebooks simply use the default RS typeface for instance so it’s quite complex to measure.

What’s important though, is that we’d better have some kind of bulletproof set of RS typefaces. Bulletproof is the keyword here, since it is difficult to imagine a set that will satisfy everybody. There won’t be any silver bullet.

As a matter of fact, more people systematically change the publisher’s typeface than those who never do it. So implementers might end up with a huge share of users systematically changing the typeface and could adjust the UX accordingly (global setting applying the typeface in all books).

It also implies we’d better have fonts providing with the largest character sets possible.

Why do people change the typeface?

Legibility. (and I’m including dys typefaces in there since it is kind of related to this issue).

In some way, I feel like this justifies we must change the typeface for (at least) body copy by any means necessary – and absolutely everything for dys.

As an aside, respondents don’t hesitate to throw the publisher/graphic designer under the bus when they feel they made an abysmal choice of typeface(s).

Other reasons were given, the most interesting ones being:

• trying new fonts for fun: maybe you can find some way to leverage the fun factor, by implementing a little game to teach typography fundamentals or something like this, IDK, but from experience, I can say that when there’s a fun factor to be found somewhere, it is usually a good idea to leverage it as it will put the user in a super good mood (UX-related);
• mood i.e. some pick a typeface that fits the mood of the publication;
• on the one hand, consistency i.e. all ebooks have the same typeface;
• on the other hand, breaking the monotony i.e. changing the typeface for each book.

Typefaces that should be included in a reading app

So, obviously, I won’t list all the fonts mentioned, I’ll try to list “categories.” Sorry in advance if those categories sound like type gangs or alternative rock bands.

The Minimalists

They don’t want an awful lot of fonts, they want the best option possible for serif and sans-serif, which means typefaces of outstanding quality (good legibility, perfect kerning, OpenType Features, etc.).

The Defaulters

Arial, Georgia, Verdana, Calibri, Times (New Roman), Segoe UI…

In other words, the fonts they find and use in MS Word.

On a related note, Bookerly and Literata have become pretty popular. That’s quite a whole new level though, as they were commissioned by Amazon and Google (and that’s a lot of money).

The eInkers

Basically, you’re given a list of typefaces you can find on a Kobo, Pocketbook or Kindle. I guess this might primarily impact some companies doing both eInk Readers and apps but there could well be a possibility to make the user feel “at home” there, by having a few of those typefaces as well.

The Slabs

Cæcilia seems to be one of the must-haves, and it’s a slab serif, so you might want to at least provide a lookalike.

The Librists

Those ones are more interested in libre/open source fonts you can find at Google Fonts, Font Squirrel, Github, SIL, etc. More on that later.

Answers include Merriweather, Bitter (slab), Vollkorn, Gentium, Ubuntu, Lato, etc.

The A11ys

Unsurprisingly, you’ll need a11y-related fonts: Open Dyslexic is a popular one, but other fonts cited in dyslexia guidelines are mentioned as well (Verdana, Trebuchet, Comic Sans, etc.).

The Printers

Some people would like to have typefaces like Garamond, Bembo, Baskerville, Times New Roman, etc.

To be honest, that kind of defy my comprehension since those ones were digitized when we didn’t know better and their screen rendering can be utterly terrible (cf. what Steve Matteson has to say about Times New Roman on screen). A lot has changed in designing typefaces for screen since but well, that’s just a personal opinion.

The Full Metal Typographers

To sum things up, they want all the fonts the platform has to offer, which means all system and locally-installed fonts.

With the advancement of Open Type Features, some issues may arise though. For instance, stylesets are unreliable, all fonts don’t manage features the same way e.g. subs, sups, ordinal, or diagonal-fraction, etc. That applies to all other categories anyway, but it could become especially nasty if you provided the user with all the fonts available on the system.

A few remarks there:

• if you’re reading between the lines, you’ll see people list typefaces they’re used to – this is even kinda obvious in Literata/Bookerly –, so you’d better focus on their category, traits and personality, which implies lookalikes/alternatives could do as well (especially because app licenses can become pretty expensive);
• if you want to meet the Printers’ demand, it seems obvious to me you should check the modern versions of those fonts first, as they have been fine-tuned for screen rendering and can offer a lot more legibility (cf. Linotype’s eText collection);
• you could bet on a flagship typeface like Amazon & Google but that’s a huge investment (custom typeface);
• we’d better be cautious about OTF as soon as possible since the user may find itself with some weird results: letters and numbers as ordinal, decorative glyphs replacing the latin alphabet as the typeface designer used stylesets for this, etc. (I’ll try to design an OTF normalize).

Installing extra fonts

It actually is a thing.

So, once again, there may be a huge bias there (tech-savvy users), but I was surprised to find out that not only respondents would be willing to install extra fonts, quite a significant number is already doing it too. Think of users installing fonts on their eReaders for instance.

However, that opens the opportunity to manage/install extra fonts, which is what the Aldiko app has been doing if I’m not mistaken. The major source of custom fonts at the moment seems to be Google Fonts for respondents but others go the extra mile and install fonts locally, in which case they might want access to all the fonts installed on the system.

You’d better be cautious about Google Fonts though, as they are often a few versions behind (and the typeface designer could have added support for extra languages, OpenType Features, etc).

This obviously is a feature requiring some extra work, and some platforms may impose limitations, so it should just be considered an interesting piece of information.

An important note: some users had to install a font for a11y purposes (e.g. dyslexia) so it’s important you meet this requirement out of the box so that they don’t have to take that extra step.

from readium-css.

Update.

The following changes were made in the previous message:

• added a category (The Full Metal Typographers);
• added remark on OTF and the need for a normalize;
• minor edits (typos, missing words, clarifications).

from readium-css.

Do you came across a cursive font stack?

from readium-css.

I’ve done a little bit of research out of curiosity, and it turned out that not having it in our use cases really was the best thing that could happen.

To sum things up, cursive is one of those inconsistent stacks, where you’ll get defaults such as Comic Sans MS on the one hand, and Apple Chancery on the other, and then you fall in the Android black hole.

You may have a cursive, which apparently can be either Coming soon or Dancing Script – I guess to cover both Comic Sans MS and Apple Chancery –, depending on the version (from Lollipop), the vendor, etc.

So there’s probably a possibility to find a consistent font stack, post Android 5 – cursive being Droid Serif post Jellybean – but don’t take my word for it as I only researched stock Android (not the modified versions).

In any case, we would have had to embed a script since the minimum version of Android we’re targeting is 4.4.4 (KitKat).

from readium-css.

I wanna go with "Apple Chancery", "Zapf Chancery", "Lucida Handwriting", "Segoe Script", "URW Chancery L", cursive; what do you think? I want to avoid Comic Sans with "Zapf Chancery", "Lucida Handwriting", "Segoe Script", but very untestet.

from readium-css.

Well, it’s really hard to tell as I can’t test it myself at the moment but Segoe Script might save the day, according to this Wiki list.

You can cross this list with the official listing on MS’ website. This is how I’ve done a lot of research, which I could then validate by testing those font-stacks.

from readium-css.

I'll test it :)

from readium-css.

So, in the spirit of the whole project, I’ll be providing implementers with a super simple utility to:

1. compare the fonts to an arbitrary default (mainly serif and sans-serif, but you can use an explicit value);
2. check fonts’ support for different languages;
3. check font’s support for the OpenType features we’re using.

I’ve just init’d this webpage and will make it interactive ASAP (right now, you must have fonts installed and edit the variables via the dev tools).

This should also help with rendering on different platforms.

You should get something like this but I must still put some fallbacks in there for IE11.

This is simply an improved version of the utility I created to check the alternatives listed in my previous message, so I know it can help as those details are not necessarily documented.

from readium-css.

@JayPanoz: The notes relating to CJK fonts were helpful for me.

from readium-css.

We still have to find more font-stacks for Japanese.

The EBPAJ guide, which we’ll take as a reference, is using the following fonts:

• Serif/Ming-cho (horizontal writing) = .serif-ja → ＭＳ 明朝 (I assume latin can be proportional)
• Serif/Ming-cho (vertical writing) = .serif-ja-v → @ＭＳ 明朝 (I assume latin must be monospaced)
• Sans Serif/Gothic (horizontal writing) = .sans-serif-ja → ＭＳ ゴシック (I assume latin can be proportional)
• Sans Serif/Gothic (vertical writing) = .sans-serif-ja-v → @ＭＳ ゴシック (I assume latin must be monospaced)

At minimum, we should provide:

• Monospaced Ming-cho-type font
• Monospaced Gothic-type font

With this minimum character set: JIS X 0213:2004 (Surrogate Pair area of Unicode are also included).

So it looks like we can build font-stacks from this early comment.

Gothic (sans-serif)

font-family: "HiraKakuPro-W3", "Hiragino Kaku Gothic Pro W3", "Hiragino Kaku Gothic Pro", "ヒラギノ角ゴ Pro W3", "メイリオ", Meiryo, "游ゴシック", YuGothic, "ＭＳ Ｐゴシック", "MS PGothic", "ＭＳ ゴシック", "MS Gothic", sans-serif;

Mincho (serif)

font-family: "HiraMinPro-W3", "Hiragino Mincho Pro W3", "Hiragino Mincho Pro", "ヒラギノ明朝 Pro W3", "游明朝", YuMincho, "HG明朝E", "ＭＳ Ｐ明朝", "MS PMincho", "ＭＳ 明朝", "MS Mincho", serif

Isn’t it fun that we had that since the beginning?

from readium-css.

So…

Serif (Mincho) + horizontal writing

font-family: "ＭＳ Ｐ明朝", "MS PMincho", "Hiragino Mincho Pro", "ヒラギノ明朝 Pro W3", "游明朝", "YuMincho", "ＭＳ 明朝", "MS Mincho", "Hiragino Mincho ProN", serif;

Serif (Mincho) + vertical writing

font-family: "ＭＳ 明朝", "MS Mincho", "Hiragino Mincho Pro", "ヒラギノ明朝 Pro W3", "游明朝", "YuMincho", "ＭＳ Ｐ明朝", "MS PMincho", "Hiragino Mincho ProN", serif;

Sans Serif (Gothic) + horizontal writing

font-family: "ＭＳ Ｐゴシック", "MS PGothic", "Hiragino Kaku Gothic Pro W3", "ヒラギノ角ゴ Pro W3", "Hiragino Sans GB", "ヒラギノ角ゴシック W3", "游ゴシック", "YuGothic", "ＭＳ ゴシック", "MS Gothic", "Hiragino Sans", sans-serif;

Sans Serif (Gothic) + vertical writing

font-family: "ＭＳ ゴシック", "MS Gothic", "Hiragino Kaku Gothic Pro W3", "ヒラギノ角ゴ Pro W3", "Hiragino Sans GB", "ヒラギノ角ゴシック W3", "游ゴシック", "YuGothic", "ＭＳ Ｐゴシック", "MS PGothic", "Hiragino Sans", sans-serif;

Reviews and feedbacks welcome.

It is worth nothing we’re currently not declaring those font-stacks like that, but “polyfilling” the EBPAJ guide.

So I’ll probably add those font-stacks in the form of CSS variables so that they can be used for unstyled Japanese publications.

We can consider this issue can be closed quickly (yeah) since we did our outmost at default font-stacks. I’m keeping it open to gather hypothetical feedbacks.

from readium-css.

This is now in docs, in a much better shape than this issue.

Any issue should be dealt with on a language/script basis, starting today.

from readium-css.