search

readium / readium-css

🌈 A set of reference stylesheets for EPUB Reading Systems, starting with Readium Mobile
https://readium.org/readium-css/
BSD 3-Clause "New" or "Revised" License
90 stars 20 forks source link

Font stacks for Default styles (and UI) #4

Closed JayPanoz closed 6 years ago

JayPanoz commented 7 years ago

Since we agreed we need an book-oriented stylesheet, I’ll try to provide implementers with reliable font stacks making the most of pre-installed fonts.

For some languages, we may have to fill the gaps, and use libre/open source fonts like Noto Serif for instance. How to manage that is still unclear but I’d like to find a solution which is optimized i.e. not loading the whole 20mb font if there is a possibility to load only a subset (unicode range).

Fundamentals

UA defaults if no font-family is set usually are:

You could force Android using a serif font by declaring 

font-family: “Times New Roman”;

But it will be resolved to Droid Serif.

For generic families (sans-serif, serif, monospace), you’ll usually get:

Historically, anything monospace has had a font-size of 13.33px so you’d better be cautious about that. A margin of 1em will indeed be 13.33px for pre.

Finally, rendering engines fall back on a glyph basis. If a glyph is not available in the preferred font, it will check if it is in the second one, and so on and so forth, for each glyph.

UI

If you want a system font stack, it already exists. 

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

This is a modernized version taking popular Linux distros and emoji into account.

Default

For latin, I’ll privilege fonts with good Open Type support. I’ll test them using one of my own “web apps.” What I can already say is that fonts OSs have been adding since 4–5 years tend to ship with OT features so we can leverage that.

For CJK/RTL, I’ll pick fonts with the widest set of glyphs available. Once again, we may have to fill the gaps so this is a more complex issue.

JayPanoz commented 7 years ago

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.

Typeface Small-caps Oldstyle nums Linear nums Proportional nums Tabular nums
Iowan Old Style ✓ ✓ ✓ ✓ ✓
Sitka Text ✓ ✓ ✓ ✓ ✓
Droid Serif ✕ ✕ ✕ ✕ ✕

Modern (serif)

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

Serif will resolve to Droid Serif on Android.

Typeface Small-caps Oldstyle nums Linear nums Proportional nums Tabular nums
Athelas ✕ ✕ ✕ ✕ ✕
Constantia ✓ ✓ ✓ ✓ ✓
Droid Serif ✕ ✕ ✕ ✕ ✕

Neutral (sans)

font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
Typeface Small-caps Oldstyle nums Linear nums Proportional nums Tabular nums
San Fransisco ✓ ✕ ✕ ✓ ✓
Segoe UI ✓ ✓ ✓ ✓ ✓
Roboto ✓ ✓ ✓ ✓ ✓
Helvetica Neue ✕ ✕ ✕ ✓ ✓

Humanist (sans)

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

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

Typeface Small-caps Oldstyle nums Linear nums Proportional nums Tabular nums
Seravek ✓ ✓ ✓ ✓ ✓
Calibri ✓ ✓ ✓ ✓ ✓
Roboto ✓ ✓ ✓ ✓ ✓

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.

JayPanoz commented 7 years ago

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

Targets:

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.

JayPanoz commented 7 years ago

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).

JayPanoz commented 7 years ago

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

Latin

Amharic (am)

Arabic (ar)

Bengali/Bangla (bn)

Tibetan (bo)

Cherokee (chr)

Gujarati (gu)

Hebrew (he)

Hindi (hi)

Armenian (hy)

Inuktitut (iu)

Japanese (ja)

Khmer (km)

Kannada (kn)

Korean (ko)

Lao (lo)

Malayalam (ml)

Oriya (or)

Punjabi (pa)

Sinhalese (si)

Tamil (ta)

Telugu (te)

Thai (th)

Chinese (zh-cn)

Chinese — Hong Kong (zh-hk)

Chinese - Taiwan (zh-tw)

JayPanoz commented 7 years ago

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:

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.

JayPanoz commented 6 years ago

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?

JayPanoz commented 6 years ago

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.

laudrain commented 6 years ago

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

JayPanoz commented 6 years ago

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

laudrain commented 6 years ago

Done.

JayPanoz commented 6 years ago

Thanks!

JayPanoz commented 6 years ago

@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.

laudrain commented 6 years ago

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.

JayPanoz commented 6 years ago

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):

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

JayPanoz commented 6 years ago

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.

llemeurfr commented 6 years ago

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.

JayPanoz commented 6 years ago

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.

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.

laudrain commented 6 years ago

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.

JayPanoz commented 6 years ago

Ah pretty interesting, thanks.

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

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.

JayPanoz commented 6 years ago

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:

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.

JayPanoz commented 6 years ago

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.

JayPanoz commented 6 years ago

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:

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:

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.

JayPanoz commented 6 years ago

Update.

The following changes were made in the previous message:

maddesigns commented 6 years ago

Do you came across a cursive font stack?

JayPanoz commented 6 years ago

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).

maddesigns commented 6 years ago

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.

JayPanoz commented 6 years ago

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.

maddesigns commented 6 years ago

I'll test it :)

JayPanoz commented 6 years ago

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.

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

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.

JayPanoz commented 6 years ago

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.

diacritics

otf

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.

JayPanoz commented 6 years ago

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:

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:

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:

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.

MarionBerthaut commented 6 years ago

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.

strarsis commented 6 years ago

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

JayPanoz commented 6 years ago

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:

At minimum, we should provide:

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?

JayPanoz commented 6 years ago

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.

JayPanoz commented 6 years ago

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.