Font Best Practices

[Tex2002ans]

Originally Posted by AliceWonder

Readers without monospace fonts are an unfortunate decision because there are legitimate reasons for publishers to use them where a variable-width font does not give the atmosphere to the reader.

Yes, but this is why you lay down multiple fallbacks, just in case.

HTML:

<p>To open the Index Editor select the menu item <span class="menuitem">Tools→Index→Index Editor</span> or its keyboard shortcut:</p>

CSS:

span.menuitem {
    font-family: monospace, courier, sans-serif;
    font-size: .9em;
}

If the reader doesn't support monospace, then it will turn sans-serif. And if anything, it'll be a slightly smaller font size than the surrounding text.

IF the device then doesn't support embedded fonts, doesn't have monospace, doesn't have sans-serif, doesn't even support CSS (and doesn't apply/overrides your small font size)... THEN maybe you can shrug your shoulders and say you tried your best... and tell them to stop using Moon+ Reader.

Originally Posted by Hitch

It has to do with years of experience, in making hundreds and thousands of books, on untold numbers of devices, and seeing everything that can, and does, go wrong.

[...]

As I tried to explain, initially, I have no issue with them when used in a limited way. As long as they aren't used for the reading material, by and large, hey--your book.

The thread is called "Font Best Practices", so we give out the best practices to make the books work across all readers, with proper fallbacks...

But no, no... fight the advice tooth and nail from those who made hundreds/thousands of books tested across dozens of devices from all form factors.

[AliceWonder]

It has nothing to do with comprehension. It has to do with years of experience, in making hundreds and thousands of books, on untold numbers of devices, and seeing everything that can, and does, go wrong.

Earlier in this thread, someone mentioned they hated bundled fonts because the weight was not thick enough for how the screen on their device works. Yet because device makers chose not to include a monospace font, those who need a monospace have no choice but to bundle one.

Wouldn't it make more sense for devices to include a monospace font that looks good on their device even if only a small percentage of books need it?

Nothing would be harmed by including one, and books that do use a monospace could leave it up to the device to use the best one.

[AliceWonder]

Originally Posted by Tex2002ans

The thread is called "Font Best Practices", so we give out the best practices to make the books work across all readers, with proper fallbacks...

But no, no... fight the advice tooth and nail from those who made hundreds/thousands of books tested across dozens of devices from all form factors.

Yeah, but the opening post was asking about woff2 vs ttf.

Devices and software seem to be really behind tech as so few support woff2 even though its been around for ages now so that question is answered and the thread has gone a different direction.

As far as working across all readers, developing to the minimum always will result in mediocrity. Web developers don't develop for IE6 anymore.

[JSWolf]

Originally Posted by AliceWonder

Earlier in this thread, someone mentioned they hated bundled fonts because the weight was not thick enough for how the screen on their device works. Yet because device makers chose not to include a monospace font, those who need a monospace have no choice but to bundle one.

Wouldn't it make more sense for devices to include a monospace font that looks good on their device even if only a small percentage of books need it?

Nothing would be harmed by including one, and books that do use a monospace could leave it up to the device to use the best one.

There is a monospace font that looks OK and will work with eInk and is free. It's called Dark Courier.

https://www.wfonts.com/font/dark-courier

Using this will look better and work better for eInk. And if it works on eInk, it will also work on LCD.

[GrannyGrump]

Is Dark Courier redistributable? Quick google didn't find licensing information, just some comments on free font sites that it is "freely distributed" (such comments being semantically meaningless).
It seems to originate from Hewlett-Packard, what do they say about it?

My search skills suck.

[najgori]

yeah, right.
and moby dick is crap literature because whale is not a fish.
"from print to ebooks" is five years old book with some bad coding, but that does not mean that monospace font cannot be used in ebooks, as heading in this case.
2 different things.
& to quote david carson: "don't mistake legibility for communication"

Originally Posted by JSWolf

You've done some things wrong. Left/right margins, monospace headers, paragraph spaces, and no indents make for one not nice eBook to try to read. If you cannot get your eBook formatting correct, why should anyone actually bother to take the advice of what's in the book?

[Hitch]

Originally Posted by AliceWonder

Yeah, but the opening post was asking about woff2 vs ttf.

Devices and software seem to be really behind tech as so few support woff2 even though its been around for ages now so that question is answered and the thread has gone a different direction.

As far as working across all readers, developing to the minimum always will result in mediocrity. Web developers don't develop for IE6 anymore.

Most people "developing" eBooks, to use your terminology, are doing so to sell them. Therefore, they want those eBooks to be legible and attractive, providing a good reader experience, across all, or most, of the available devices.

Sure--someone can create an eBook that aspires to the "best" available coding--whatever that might be. For example, woo-woo, let's use SVG images in our ePUB, that we're then going to use for a MOBI for Amazon! Wow, all the advantages....but then, oh, yeah, right, NONE of those images would be visible to someone with a KF7 reader. Hell, just embedding images and then coding them in percentages for display (e.g., width:80%) won't work right for KF7 devices, so on most of those, the image would be blown up the full-width of the screen, no matter how blurry or distorted it might make that image. So, commercial coders will hand-code all the fallback coding, to make sure that each image does display correctly--no matter the device. That's developing for IE6, effectively. (Of course...if we don't, the client stands a very good chance of having the book KQNed--Kindle Quality Noticed--too, so..)

As I said previously--you have one book to worry about, and you can do whatever blows your skirt up. And if you choose, through a coding decision, to not make the book usable to the readers with today's equivalent of IE6, that's your choice. I'm not saying you are doing that--I'm simply discussing your comment. That's entirely your right. Most people prefer to go for the largest-possible distribution option.

I mean, after all--you said that you're deliberately trying to make your book readable by those with poor eyesight or other reading impairments, yes? Not really much difference between doing something like that, and ensuring that Suzie Q with her old Kindle Keyboard can view the file in its entirety, right?

Hitch

[AliceWonder]

Just a note - requiring font subsetting w/o using software to do so, solved problem.

For monospace fonts where I just need 7-bit ASCII

pyftsubset LiberationMono-Regular.ttf \
  --unicodes=U+0020-007E \
  --output-file="LiberationMono-Regular-ascii.ttf"

(same with Bold, Italic, and BoldItalic variants if needed)

for other fonts - for western Latin languages I just created a subset that covers everything in Latin 1 (ISO-8859-1), Latin 9 (ISO-8859-15), and Windows-1252 plus two glyphs that are quite common.

Text file called WesternLatin.txt containing:

U+0020-007E
U+00A0-00FF
U+0152-0153
U+0160-0161
U+0178
U+017D-017E
U+0192
U+02C6
U+02DC
U+2013-2014
U+2018-201A
U+201C-201E
U+2020-2022
U+2026
U+2030
U+2039-203A
U+20AC
U+2116
U+2117
U+2122

Then I can run

pyftsubset FontFile.ttf \
  --ignore-missing-glyphs \
  --unicodes-file=WesternLatinRange.txt \
  --output-file="FontFile-wlatin.ttf"

For ornamental glyphs (not most emojis though I think some are now in the official emoji list) I create a subset that has 7-bit ASCII plus three unicode blocks that have all the ornamentals I ever use

U+0020-007E
U+2300-23FF
U+2600-26FF
U+2700-27BF

I include ASCII even though it is duplication if I also have western latin from same file because IMHO a font file w/o 7-bit ASCII is broken. But anyway I use that same way as Western Latin.

And obviously I could do the same if I needed, say, Greek or whatever.

It may result in font files slightly larger than if I only included the glyphs actually used but they are still radically smaller than the original fonts - and it means I can edit the content w/o worrying about needing to re-subset the fonts.

Just make sure to use unicode-range in the @font-face if you end up using two different subsets from the same font-family, font-style, font-weight, and font-variant.

[AliceWonder]

Something I still need to research is which unicode ranges I would need for a subset that covers MathML.

I suspect though for MathML a single font would have way too many glyphs because most MathML is very specific in the glyphs in needs, so a one-size-fits-all approach that I am using for western Latin content is probably not the best approach for MathML but I'll have to look at font size for a MathML specific subset. If its ~ 100kB or smaller then it probably is an okay approach. Especially as WOFF2 gains adoption allowing even further size reduction.

[AliceWonder]

Originally Posted by JSWolf

There is a monospace font that looks OK and will work with eInk and is free. It's called Dark Courier.

https://www.wfonts.com/font/dark-courier

Using this will look better and work better for eInk. And if it works on eInk, it will also work on LCD.

I'll be buying a Kobo as soon as I can get to Walmart (epileptic, don't drive) so assuming that is what you are referring to as eInk then I will be able to evaluate how my chosen fonts compare.

btw my eyes aren't the greatest, which is one of the reasons I like Clear Sans so much - at least with PDF content compiled with LaTeX, my eyes don't get tired when Clear Sans is the body font - but they do with many other fonts.

It will be interesting to see if that holds true on a Kobo.

[Tex2002ans]

Originally Posted by AliceWonder

Something I still need to research is which unicode ranges I would need for a subset that covers MathML.

This is a good place to start:

https://en.wikipedia.org/wiki/Mathem...ols_in_Unicode

Originally Posted by AliceWonder

I suspect though for MathML a single font would have way too many glyphs because most MathML is very specific in the glyphs in needs, so a one-size-fits-all approach that I am using for western Latin content is probably not the best approach for MathML but I'll have to look at font size for a MathML specific subset.

You could look at the proper OpenType Maths fonts. There aren't many out there.

https://en.wikipedia.org/wiki/Catego...Type_typefaces

STIX is one of the high-quality free + open ones:

https://www.stixfonts.org/

[AliceWonder]

Originally Posted by Tex2002ans

This is a good place to start:

https://en.wikipedia.org/wiki/Mathem...ols_in_Unicode

Thanks, that looks like it pretty much has everything.

You could look at the proper OpenType Maths fonts. There aren't many out there.

https://en.wikipedia.org/wiki/Catego...Type_typefaces

STIX is one of the high-quality free + open ones:

https://www.stixfonts.org/

Thank you. In LaTeX I tend to use commercial Lucida Bright or MathTime Pro2 (I paid for both) - but those are Type 1 fonts, I don't know what the TTF/OTF equivalents support. I know Lucida Math fonts in TTF/OTF exist but aren't free, and I doubt mtpro2 would be free (if it even exists outside of LaTeX)

[Tex2002ans]

Originally Posted by AliceWonder

Thanks, that looks like it pretty much has everything.

For the technical details, you'll also want to check out:

Unicode ® Technical Report #25 "UNICODE SUPPORT FOR MATHEMATICS" (PDF)

And since you're familiar with LaTeX, I assume you know about unicode-math? That's about the only way I know of that easily generates a lot of those obscure maths symbols for you.

Side Note: You may also be interested in Will Robertson's (creator of unicode-math) two TUG talks:

TUG 2015: Reconciling unicode-math with LaTeX2e mathematics
TUG 2018: Progress of fontspec and unicode-math

Originally Posted by AliceWonder

Thank you. In LaTeX I tend to use commercial Lucida Bright or MathTime Pro2 (I paid for both) - but those are Type 1 fonts, I don't know what the TTF/OTF equivalents support. I know Lucida Math fonts in TTF/OTF exist but aren't free, and I doubt mtpro2 would be free (if it even exists outside of LaTeX)

That list is actual OpenType fonts that have the MATH tables in them. This means they're actually usable for all the complex Maths (and I assume MathML).

A bunch of those ol' Type 1 and TeX fonts were all hackishly done. Sure, it worked in PDF and Print where you only care about the finalized LOOK... but absolutely no way those hacks would work in the web+ebooks, where things need to be kept Accessible, and users are able to copy/paste, change fonts, font sizes, display sizes, etc.

It's part of the big reason why AMS + others all pushed to get Maths added to the actual Unicode standard.

[AliceWonder]

Yeah, it looks like subsetting math is beyond what I would be able to do well - subsetting probably has to do with particular fields as far as what would be likely to be useful.

My math typesetting experience is limited to undergrad calculus level so I don't have experience in the more complex but open source math textbooks were always a dream of mine, it angered me that textbooks were so expensive when 95% of the content between two editions were identical, pretty much only the homework questions changed - thus poor students like me couldn't just use the older edition. It was economics that forced me out of college.

-=-

It was actually MathML that introduced me to the Document Object Model - needed Math in a web page circa 2000 and didn't want an image (this was before I discovered LaTeX) and Mozilla had basic MathML support if served as XML - but of course serving as XML broke my JS that at the time was full of document.write()

I know MathML support in eBooks isn't all that universal yet, but ePub with MathML seems like a path towards open source math books and a better choice than LaTeX to PDF.

Learning about the DOM was a lightbulb moment, seeing content as a collection objects made a lot of sense.

[JSWolf]

Originally Posted by AliceWonder

I'll be buying a Kobo as soon as I can get to Walmart (epileptic, don't drive) so assuming that is what you are referring to as eInk then I will be able to evaluate how my chosen fonts compare.

btw my eyes aren't the greatest, which is one of the reasons I like Clear Sans so much - at least with PDF content compiled with LaTeX, my eyes don't get tired when Clear Sans is the body font - but they do with many other fonts.

It will be interesting to see if that holds true on a Kobo.

When you do get a Kobo, don't embed any fonts in your eBook. Try the fonts that come with the Kobo and see what you think.