Font Best Practices

[AliceWonder]

Oh I'll definitely be trying both. I already do both to make sure the magazine is readable w/o embedded fonts.

In some places embedded are a must, such as SVG images with precisely placed text - w/o embedded fonts, the metrics are different and they look bad.

[Notjohn]

> Do you want every book you read to look the same too?

I do, yes, or anyhow not looking different for the sake of looking different. Fancy fonts get in the way of melding my mind to the author's.

[JSWolf]

Originally Posted by Notjohn

> Do you want every book you read to look the same too?

I do, yes, or anyhow not looking different for the sake of looking different. Fancy fonts get in the way of melding my mind to the author's.

I do like my eBooks to look the same. I like a clean look, not one of these sloppy looks. To me, sloppy is too much space wasted for charpter headers, wide margins, line-height set in CSS, paragraph spaces or any size (eve .2em is sloppy), small text size instead of the default for the main text, offset text in a smaller font size, chapter headers used as links to the internal ToC, embedded fonts that do not work and/or do not work, graphics used instead of tables for columned text, graphics used instead of other characters, don't use a large indent or no indent.

I prefer an eBook that when used on a Kobo can be customized as the user wants. Change the font, change the margins, change the line height, and change the font size. So don't set a L/R margin, don't set a line height, and don't set a font size for the main text.

[Hitch]

Originally Posted by Notjohn

> Do you want every book you read to look the same too?

I do, yes, or anyhow not looking different for the sake of looking different. Fancy fonts get in the way of melding my mind to the author's.

NJ, you are COMPLETELY full of it. Did all those "fancy fonts" interrupt your reading pleasure for the 50 years of reading you did before eBooks? NO, they didn't. Somehow, print designers designed books and laid them out, since the time of Gutenberg, and everybody managed to read them without whingeing about bloody fonts, generally.

I frequently wonder about what sort of world we're creating here, where every wanker thinks that every single experience has to be hand-tailored for them. Instead of just taking a damn book and READING IT, which is the intended use.

Sure, seeing 100K words in Comic Sans would be bad. But someone using comic sans, as appalling as that would be, for a title page or Chapter heads, won't kill anyone.

Hitch

[meeera]

Originally Posted by Hitch

NJ, you are COMPLETELY full of it. Did all those "fancy fonts" interrupt your reading pleasure for the 50 years of reading you did before eBooks? NO, they didn't. Somehow, print designers designed books and laid them out, since the time of Gutenberg, and everybody managed to read them without whingeing about bloody fonts, generally.

I frequently wonder about what sort of world we're creating here, where every wanker thinks that every single experience has to be hand-tailored for them. Instead of just taking a damn book and READING IT, which is the intended use.

We want reading matter to be readable. This was discussed at length in the beginning of this thread. People who design for tablets/computer screens often don't realise that the same fonts on eink can be completely unreadable. That's not (generally) an issue with people designing for print.

Having said that, I did once borrow a paper book that I returned straight away to the library after opening it. It happens.

[AliceWonder]

It's not a matter of using "fancy fonts" - it is a matter of using fonts that we feel add to the experience of what we are writing.

When doing research on hyphenation, I saw some complaints that using the soft-hyphen character (U+00AD) resulted in a ? glyph on some readers. I don't know for sure, but I would bet the issue is the device manufacturer has a default font w/o that glyph even though it is included in just about every 8-bit encoding since Latin-1 and if I remember correctly from years back is even part of the HTML 4.0 specification for soft hyphenation.

Embedding the font is the only way we can be sure every glyph we use is available - even with common codepoints like U+00AD.

[doubleshuffle]

Originally Posted by Hitch

I frequently wonder about what sort of world we're creating here, where every wanker thinks that every single experience has to be hand-tailored for them. Instead of just taking a damn book and READING IT, which is the intended use.

But hand-tailoring enhances enjoyment. Since I replaced with my own and bolded the heroes' names in all my adventure and crime novels I have been enjoying them twice as much. And don't you dare take that away from me. It's my RIGHT!!!!

[Tex2002ans]

Originally Posted by AliceWonder

When doing research on hyphenation, I saw some complaints that using the soft-hyphen character (U+00AD) resulted in a ? glyph on some readers. I don't know for sure, but I would bet the issue is the device manufacturer has a default font w/o that glyph [...]

Soft Hyphens are horrendous all around. I wrote about the many disadvantages most recently here:

https://www.mobileread.com/forums/sh...42#post3649942

Most infuriating to me lately is:

• Interfering with real hyphenation support
  • Most modern devices now have automatic hyphenation
  • Plus CSS hyphens support is getting better all the time.
• Breaking search
• Messing up dictionary lookup
• Highlighting
  • For example, on phone, long press+hold to highlight entire word... soft hyphens typically mess this up.
  • Same with dragging finger across words. In many programs, highlighting stops at soft hyphens.

[JSWolf]

Originally Posted by Hitch

NJ, you are COMPLETELY full of it. Did all those "fancy fonts" interrupt your reading pleasure for the 50 years of reading you did before eBooks? NO, they didn't. Somehow, print designers designed books and laid them out, since the time of Gutenberg, and everybody managed to read them without whingeing about bloody fonts, generally.

I frequently wonder about what sort of world we're creating here, where every wanker thinks that every single experience has to be hand-tailored for them. Instead of just taking a damn book and READING IT, which is the intended use.

Sure, seeing 100K words in Comic Sans would be bad. But someone using comic sans, as appalling as that would be, for a title page or Chapter heads, won't kill anyone.

Hitch

Speaking of fonts, the answer is that in most cases unless it was Charis SIL embedded, the answer is yes, it did interrupt my reading enjoyment as the fonts are too light. When I had Sony Readers, I was unable to do anything about the fonts on the Reader. That's why I got into making changes to eBooks. I've seem many eBook with some form of Garamond embedded. That font makes for a poor reading experience unless you can override or up the weight. Then there is the graphic images used as text that also don't work and make for a poor reading experience.

The problem is that when fonts are embedded, they aren't tested on an eInk screen to see if they are acceptable as is. Yes they may be OK in print, but they are not OK for eInk and in some cases, not even OK on an LCD screen (iPhone, iPad).

I can remove embedded fonts that I don't want and fix formatting that I don't like, but should I have to?

[JSWolf]

Originally Posted by AliceWonder

It's not a matter of using "fancy fonts" - it is a matter of using fonts that we feel add to the experience of what we are writing.

When doing research on hyphenation, I saw some complaints that using the soft-hyphen character (U+00AD) resulted in a ? glyph on some readers. I don't know for sure, but I would bet the issue is the device manufacturer has a default font w/o that glyph even though it is included in just about every 8-bit encoding since Latin-1 and if I remember correctly from years back is even part of the HTML 4.0 specification for soft hyphenation.

Embedding the font is the only way we can be sure every glyph we use is available - even with common codepoints like U+00AD.

In some reading software, soft hyphens are not supported. It's not a matter of the character not being there. Plus, a lot of reading software supports hyphens anyway. Kindles support soft hyphens, but ADE (RMSDK) does not and doesn't need to as it supports hyphenation on current Readers that use it. And in some cases, even if soft hyphens are displayed correctly, they can break searching.

[Hitch]

Originally Posted by meeera

We want reading matter to be readable. This was discussed at length in the beginning of this thread. People who design for tablets/computer screens often don't realise that the same fonts on eink can be completely unreadable. That's not (generally) an issue with people designing for print.

Having said that, I did once borrow a paper book that I returned straight away to the library after opening it. It happens.

Yes, but the reality is, probably 99% of all ebooks--ALL--don't even HAVE an embedded bdy font. This isn't a problem in search of a solution; it's a solution claiming that the "problem" is bigger than it is. Could you ever have seen a paper book--or eBook--with unreadably bad fonts? Sure. But generally, or even 2% of the time? No. Hell, even 1% of the time? No.

Originally Posted by AliceWonder

It's not a matter of using "fancy fonts" - it is a matter of using fonts that we feel add to the experience of what we are writing.

When doing research on hyphenation, I saw some complaints that using the soft-hyphen character (U+00AD) resulted in a ? glyph on some readers. I don't know for sure, but I would bet the issue is the device manufacturer has a default font w/o that glyph even though it is included in just about every 8-bit encoding since Latin-1 and if I remember correctly from years back is even part of the HTML 4.0 specification for soft hyphenation.

Embedding the font is the only way we can be sure every glyph we use is available - even with common codepoints like U+00AD.

The problem is--if you embed a font and subset it, having forgotten to ADD the soft-hyphen, then when it is deployed in use, beause Reader X has hyphenation, badda-bing, you get the ? or X or whatever that reader uses to shows to indicate a missing character.

I had this happen to us with Amazon, of all places, in the LookInside. Not exactly the same thing, but similar--we had put a body font primary in a given book. Overridable, of course, with a simple click. (And on Paperwhite family devices, only visible when affirmatively selected). Amazon, for reasons I still don't understand, displayed that font in the LITB, not their own Georgia. However, while Amazon didn't override the font--they did override the rendering and rendered the book with ligatures. Which, of course, we had not embedded in the book for all the obvious reasons.

So, what happened? The book displayed on the LITB with a bunch of missing characters/letters. I freely admit, took me a few minutes to figure out WTH had happened! (So now, we embed ligs, too. That's the long way to explain why I'm saying, make sure you embed soft hyphens!)

Originally Posted by doubleshuffle

But hand-tailoring enhances enjoyment. Since I replaced with my own and bolded the heroes' names in all my adventure and crime novels I have been enjoying them twice as much. And don't you dare take that away from me. It's my RIGHT!!!!

Bless you, Dubbshuff, bless you for that.

Originally Posted by JSWolf

Speaking of fonts, the answer is that in most cases unless it was Charis SIL embedded, the answer is yes, it did interrupt my reading enjoyment as the fonts are too light. When I had Sony Readers, I was unable to do anything about the fonts on the Reader. That's why I got into making changes to eBooks. (snippage)

And the world is a better place, no doubt, Jon, as we wouldn't have had the divine pleasure of your company here on MR without that. :-)

The problem is that when fonts are embedded, they aren't tested on an eInk screen to see if they are acceptable as is. Yes they may be OK in print, but they are not OK for eInk and in some cases, not even OK on an LCD screen (iPhone, iPad).

Agreed.

I can remove embedded fonts that I don't want and fix formatting that I don't like, but should I have to?

No, Jon, you oughtn't, but what device s it that you're using that doesn't simply allow you to override that? Are there still devices in wide circulation that don't allow the user to simply click and override embedded body fonts? I mean, at Amazon, they've gone the extra step to literally remove a font if it's on the BODY tag. They're not kidding around, lol.

Hitch

[AliceWonder]

Originally Posted by Hitch

The problem is--if you embed a font and subset it, having forgotten to ADD the soft-hyphen, then when it is deployed in use, beause Reader X has hyphenation, badda-bing, you get the ? or X or whatever that reader uses to shows to indicate a missing character.

Not if the reader does fonts the right way.

When the CSS specified font does not have the glyph, then the readers should attempt to get the glyph from the font type specified.

body p {
  font-family: 'Whatever Font without Euro', sans-serif;
}

If the Euro is used, since the font does not have that code-point, it would be fetched from the default sans-serif font if it has the code point.

[AliceWonder]

Originally Posted by JSWolf

And in some cases, even if soft hyphens are displayed correctly, they can break searching.

They break searching because of bugs in the reader.

And a lot of readers support automated hyphenation *IN WESTERN LATIN* but seriously get it wrong or do not support it at all in other languages. As such, readers *should* support soft hyphens so ePub in those languages will work right.

But even if they don't, the glyph then would be a zero-width glyph if their default fonts had U+00AD but it seems there isn't something like WGL4 was to Windows --- not even for western Latin glyphs --- that ePub authors can know the readers all support, so embedding their own fonts is the only way to know the glyphs they need are there.

[AliceWonder]

Originally Posted by Tex2002ans

Soft Hyphens are horrendous all around. I wrote about the many disadvantages most recently here:

*snip*

Thank you, I'll read it.

I agree that device and CSS is where hyphenation belongs, it's presentation and not content - separation of presentation from content is *always* better when possible.

But that doesn't change the fact that some readers display a ? at soft hyphens because their default fonts do not include the U+00AD.

Since U+00AD is part of HTML for soft hyphenation and ePub does not forbid it, readers really should include that glyph even if they don't support soft hyphenation itself.

[AliceWonder]

What I would really like, and I hope CSS eventually supports this, is a way for the author to specify some custom hyphenation for specific words that automated hyphenation sometimes gets wrong.