Font Best Practices

[DNSB]

Originally Posted by BetterRed

My knowledge of baseball players, starts/stops with Willy Mays and Babe Ruth (just their names - nothing else), I got the other chap's name from googling 'best baseball player 2019' - IIRC Ian Chappell played baseball in winter.

End of digression - else the font mavens will get there glyphs mixed up with their French cues and that'll be the EOTWAWKI

I've heard of the Yankees and Green Bay Packers, but maybe they're gridiron 'footie' <<== my most loathed Australian diminutive Ψ³

BR

The four players I mentioned were hockey players. For many Canadians, that's the closest to a true religion we have.

[theducks]

Originally Posted by Turtle91

Isn't that simply due to the device/app you are using? My reading app allows me to overide even when all those things are set in the CSS...

I understand that some of the older devices are limited in what they can do, and I understand the argument of wanting to sell to the biggest range of people possible, etc. However, at some point, users need to realize that they may want to update from their palm-pilot if they want to get a more enjoyable experience...

I am using a Aura 2 and a Kindle 4 (I wore out 2 EzReaders. Button/board failures. I have replaced the Battery in the K4. It looks sad, but it still runs fine, so why replace it?

Even when I had a well paying Technicians job, I bought for the long run. Not turning it in for a new model just to have the new one. Run it till it drops
or undependable or too expensive (Shop rates are insane here and backyard mechanics like myself can only do so much without fancy test equipment) to keep running

[AliceWonder]

Originally Posted by theducks

alice
In the high tech world we used the term: 'Bleeding edge"
Designers of product for use with older devices should stay far-far away from the edge.

There's a difference between staying away from the bleeding edge and continuing to embrace what was deprecated long ago.

Technical Debt is another term in the high tech world - it involves the high cost of upgrading something to current standards, and it isn't cheap.

Don't design for what is already deprecated or the cost of moving forward will bite you.

[doubleshuffle]

But then you better put a sticker on your magazine or book: "Don't bother buying if you're still using your ancient 2018 reader. I'm on the bleeding edge and not going to pay your technical debt." I'm sure that'll go down well.

[AliceWonder]

Originally Posted by doubleshuffle

But then you better put a sticker on your magazine or book: "Don't bother buying if you're still using your ancient 2018 reader. I'm on the bleeding edge and not going to pay your technical debt." I'm sure that'll go down well.

Nah - I'm testing it with Marvin on an 3rd gen iPad - using whatever default fonts Marvin already has (it doesn't respect publisher fonts, maybe there is a way to tell it to but the fact that it doesn't by default makes it the perfect test platform).

I won't exclude tech just because it doesn't work with that old reader, but I've found that generally failings of newer methods on older devices are non fatal. And that's by design of the ePub (or whatever) standard.

I know Apple likes to make changes that are fatal to force people to junk perfectly good devices and buy new, but open standards try not to.

Will my magazine look as good as it could if I designed it for old readers like Marvin?

No, it won't, but I would be very surprised if the Marvin market share wasn't shrinking... so why would I want to target it?

[Hitch]

Originally Posted by AliceWonder

There's a difference between staying away from the bleeding edge and continuing to embrace what was deprecated long ago.

Technical Debt is another term in the high tech world - it involves the high cost of upgrading something to current standards, and it isn't cheap.

Don't design for what is already deprecated or the cost of moving forward will bite you.

It's good, then, that you're not designing for the Amazon market.


Hitch

[Turtle91]

Originally Posted by AliceWonder

Nah - I'm testing it with Marvin on an 3rd gen iPad - using whatever default fonts Marvin already has (it doesn't respect publisher fonts, maybe there is a way to tell it to but the fact that it doesn't by default makes it the perfect test platform).

...

Just FYI - Marvin supports publisher fonts just fine. It also will strictly respect publisher CSS better than any other reader/app I've found... you just need to tell it to do so...

- open your book
- tap Aa
- scroll down to "Publisher's Layout" and turn it on

[AliceWonder]

Originally Posted by Turtle91

Just FYI - Marvin supports publisher fonts just fine. It also will strictly respect publisher CSS better than any other reader/app I've found... you just need to tell it to do so...

- open your book
- tap Aa
- scroll down to "Publisher's Layout" and turn it on

Oh nice!

Wish it did it automatically for text in SVG images, but it does it per book user's choice. That's good.

[JSWolf]

The thing is, if you don't need to do something fancy that may break on older software, don't do it. The simpler you can make your eBook, the better. The question is though, if you have to something that may/will break on older software, how can you get the word out not to buy it if you fit into the it will break category.

[Tex2002ans]

Originally Posted by AliceWonder

There's a difference between staying away from the bleeding edge and continuing to embrace what was deprecated long ago.

[...]

Don't design for what is already deprecated or the cost of moving forward will bite you.

Like Hitch mentioned, the reality is:

If putting this ebook for sale in the stores (Kobo, B&N, Amazon, [...]): You'll get returned sales, you'll get the quality notices, and your book will be taken down.

If you're hosting/selling this on your own site, get prepared for the massive flood of technical support emails/questions. (This is an extreme burden.)

You can't just say: "Well, use the latest iPad + iBooks combo. And make sure you push the Publisher Font button."

Originally Posted by AliceWonder

I won't exclude tech just because it doesn't work with that old reader, but I've found that generally failings of newer methods on older devices are non fatal. And that's by design of the ePub (or whatever) standard.

Purely decorative things, like CSS3 ::first-line and making it all caps, whatever. If a device doesn't support that, that doesn't detract from the book.

But when you start going way into the "bleeding edge" (SVG, MathML, WOFF2 instead of OTF, etc.), you're going to cause yourself some extreme headaches... and you will have to take into account devices that don't support that.

For example, I would love better MathML + SVG support across readers. It would make sticking equations/formulas in ebooks much easier. But the reality is, you have to design bitmap fallbacks.

Sure, I'll tweak my own workflow so I can (easily) substitute SVG + MathML in the future... but the reality now is... you always need the bitmaps.

[JSWolf]

I don't see an issue using SVG. Instead of using MathML, use a program that will convert MathML to SVG and use the SVG. The problem is that if an app doesn't support SVG, then the user will have to find a different one.

Also, besides testing with marvin, also test with ADE 2.0.1 for Windows. If it works there, it will work in Readers that use RMSDK.

[AliceWonder]

Originally Posted by JSWolf

The thing is, if you don't need to do something fancy that may break on older software, don't do it. The simpler you can make your eBook, the better.

Only the sith deal in absolutes

I agree the simpler the better - KISS - hence why I prefer a command-line workflow over something like a word processor or InDesign.

But keeping things simple at the expense of what is useful to users is a balancing act, when you deny what is useful to a large percentage of your users because a small percentage is using deprecated software, there's a point where you are doing a disservice to those who can afford to frequently pay for your product in order to satiate those who can not afford to pay for your product.

That doesn't mean screw the poor. Hell, I'm poor. Poverty is one of the reasons I only use Linux - I could never figure out Windows w/o classes I couldn't afford, and MacOS became too expensive when older hardware no longer could run the modern OS.

With Marvin, even though I'm not targeting it, I made a change to CSS because it fixed an issue with Marvin w/o breaking things on other readers. Technically it's a bug in Marvin but since Marvin is abandoned it won't be fixed, and since there was a workaround, use it.

But again compatibility is _why_ I want to embed fonts. It's the only way I can really know the glyphs I need are actually available.

Unicode and UTF-8 both predate ePub, UTF-8 is the default encoding for XML when an encoding isn't specified, and ePub requires either UTF-8 or UTF-16 (and it should deprecate the latter IMHO as a legacy encoding but not my decision)

Using arbitrary Unicode codepoints is well supported by both UTF-8 and by XML which are the fundamental building blocks of ePub. It is not bleeding edge to use what was available in (X)HTML before ePub existed.

Some readers have poor glyph coverage with their fonts, not even having all the glyphs that are part of Latin-1 (such as soft hyphen) let alone WGL4. Embedding fonts is the only way to make sure the glyphs I use really are available. That's not bleeding edge.

Soft hyphens - they should be supported because they were part of HTML before ePub existed. Should they be used? Probably not, except maybe in special cases like rare languages where automated hyphens are not well supported.

Soft hyphens break the fundamental concept of keeping layout separate from content so I agree they should be avoided except when absolutely necessary. But it really is rather pathetic that some readers do not support what I know was a part of the HTML 4.0 specification. And it is not "bleeding edge" to want to use HTML technology that existed prior to ePub becoming a thing.

The question is though, if you have to something that may/will break on older software, how can you get the word out not to buy it if you fit into the it will break category.

Write to the specification. If my ePub is written to ePub 3 specification, then someone with a reader that isn't ePub 3 compliant can't expect everything to work perfectly in their reader.

Just today I came across a reader that treats the "abbr" tag as if it had display set to none (the reader is KyBook 2) - should I not use the standard tag for noting a word is an abbreviation because it causes display issues in that reader, or should I stick to the spec and let people who use that reader know their reader is broken?

I choose the latter.

[JSWolf]

Originally Posted by AliceWonder

Only the sith deal in absolutes

I agree the simpler the better - KISS - hence why I prefer a command-line workflow over something like a word processor or InDesign.

But keeping things simple at the expense of what is useful to users is a balancing act, when you deny what is useful to a large percentage of your users because a small percentage is using deprecated software, there's a point where you are doing a disservice to those who can afford to frequently pay for your product in order to satiate those who can not afford to pay for your product.

It depends on what it is and how important it is. Can you do what you want without the more complex? Does it need to be done?

That doesn't mean screw the poor. Hell, I'm poor. Poverty is one of the reasons I only use Linux - I could never figure out Windows w/o classes I couldn't afford, and MacOS became too expensive when older hardware no longer could run the modern OS.

I'm not rich. But I am using Windows 10 because it was a free upgrade. It still can be had for free.

With Marvin, even though I'm not targeting it, I made a change to CSS because it fixed an issue with Marvin w/o breaking things on other readers. Technically it's a bug in Marvin but since Marvin is abandoned it won't be fixed, and since there was a workaround, use it.

But again compatibility is _why_ I want to embed fonts. It's the only way I can really know the glyphs I need are actually available.

Are you using ADE 2.0.1? You'll have to find a computer with Windows to run it to test your eBook. While it's OK to test with Marvin, you may be testing with webkit. You should also be testing with ADE 2.0.1.

Unicode and UTF-8 both predate ePub, UTF-8 is the default encoding for XML when an encoding isn't specified, and ePub requires either UTF-8 or UTF-16 (and it should deprecate the latter IMHO as a legacy encoding but not my decision)

Using arbitrary Unicode codepoints is well supported by both UTF-8 and by XML which are the fundamental building blocks of ePub. It is not bleeding edge to use what was available in (X)HTML before ePub existed.

Some readers have poor glyph coverage with their fonts, not even having all the glyphs that are part of Latin-1 (such as soft hyphen) let alone WGL4. Embedding fonts is the only way to make sure the glyphs I use really are available. That's not bleeding edge.

Soft hyphens - they should be supported because they were part of HTML before ePub existed. Should they be used? Probably not, except maybe in special cases like rare languages where automated hyphens are not well supported.

Soft hyphens break the fundamental concept of keeping layout separate from content so I agree they should be avoided except when absolutely necessary. But it really is rather pathetic that some readers do not support what I know was a part of the HTML 4.0 specification. And it is not "bleeding edge" to want to use HTML technology that existed prior to ePub becoming a thing.

If you use ADE 2.0.1 to test your glyphs, you'll find out if you need to embed or not. As for soft-hyphens, that's one of the things you don't need and it can be more of a hassle then it's worth. So don't use soft-hyphens.

Remember, this is ePub, not Firefox. Not everything works and not everything that doesn't work is ignored or dealt with so it looks like it might be working.

Write to the specification. If my ePub is written to ePub 3 specification, then someone with a reader that isn't ePub 3 compliant can't expect everything to work perfectly in their reader.

Just today I came across a reader that treats the "abbr" tag as if it had display set to none (the reader is KyBook 2) - should I not use the standard tag for noting a word is an abbreviation because it causes display issues in that reader, or should I stick to the spec and let people who use that reader know their reader is broken?

I choose the latter.

There are a lot of Readers/software out there that won't work with <abbr>. That's another thing to not use.

You are making an eBook for many people who use different software and even different versions of the same software. So you have to go for the lowest common denominator as possible.

[AliceWonder]

I'm not rich. But I am using Windows 10 because it was a free upgrade. It still can be had for free.

The problem isn't the cost of Windows. The problem is I did not grow up with Windows or have Windows systems in school. It is foreign to me, I can not figure out how to be productive in it, it would take classes to learn.

Linux - well, I've been using it since '98 and generally works the same way my mind does. Gnome 3 frustrates the hell out of me, but the MATE developers forked Gnome 2 so I just use that.

If you use ADE 2.0.1 to test your glyphs, you'll find out if you need to embed or not.

No, I won't. It's quite clear that just like Android phone manufacturers don't use the default Google provided fonts but use their own, that many ePub readers don't use the fonts provided by the Adobe engine (assuming that is what they use, the ePub spec does not require any particular rendering engine) but use their own.

So no, I don't know that just because a glyph is supported in ADE that it will work in every reader out there.

I assume that the Latin-1/Latin-9/Windows 1252 glyphs *mostly* work, with the exception of soft-hyphen which is in all three of those encoding but seems to not be in the fonts some readers include.

I assume many of the WGL4 glyphs commonly used in English *mostly* work.

But embedding a font is the only way to know for sure the glyphs my content uses is available.

[AliceWonder]

Here's another thing to consider - say I have high confidence every glyph is supported in 99.99% of the market share. I then don't have to embed.

But the next publication in the series uses a glyph or two that isn't. Now I have to embed and the look and feel of the publication differs between the two books in the series.

That's always a risk, but by starting with a font that has very good WGL4 glyph support and embedding it (even a subset to reduce size), I can largely avoid the issue of necessary look and feel differences between different books in the same series.