[Tex2002ans]

Originally Posted by JSWolf

I don't see an issue using SVG.

There's many devices out there that don't support properly displaying SVG (see Android readers). You also have font/background color bugs (remember back in 2014 when we talked about SVG Tables?).

Also, when you have SVG with a bitmap fallback, many readers wrongly display both images instead.

Originally Posted by JSWolf

Instead of using MathML, use a program that will convert MathML to SVG and use the SVG.

Hence why I linked to my tutorial. Using LaTeX equations as the source, then generating both SVG + bitmaps + MathML from there.

(And yes, similar could be done with MathML or LibreOffice Math as a source.)

But it would be a extremely bad idea to try to sell a MathML-only EPUB3, and then tell them "it's the standards" and they can only read on program X. (Only case you might be able to get away with that is selling an iBooks-specific EPUB, since they severely lock their ecosystem down and include MathJax in iBooks.)

Originally Posted by AliceWonder

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 [...]

Exactly, now you're getting it.

Kindles don't support it either, so it's best to avoid <abbr>.

If they were important, you would have to replicate that one using normal <span>. If not, you would have to strip them.

Originally Posted by AliceWonder

let people who use that reader know their reader is broken?

You could let them know it's busted, and hope they go to a more compliant reader... as many users always stress whenever someone comes here with "yet-another-Android-Reader-X-problems".

But it's on you, as the ebook creator, to work around known bugs. Can't just shrug your shoulders.

Originally Posted by AliceWonder

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.

Probably a good assumption.

Devices that were focused on "American" audiences like the Nook didn't have good character support.

Kindles + Kobos have quite good fallback fonts.

Android readers are more likely going to have much more expansive font support as well.

(And forget about the soft hyphen, it's abysmal.)

Originally Posted by 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. [...]

If it's only a very small handful of characters, it probably wouldn't matter if the reader sees 1 or 2 blank squares.

For example, I've worked on books where a single person's/article's name uses: Turkish dotted İ or the dotless ı, or a Czech name with the ž.

In that case, I wouldn't waste time embedding a font.

Now, if you're working on a fully Turkish or Czech book, that might be a different story.

Or I've also discussed Polytonic Greek. If the book has quite a few Greek phrases in there, then that's when I embed a font (and mark everything with proper lang + xml:lang):

https://www.mobileread.com/forums/sh...47#post3866247

Many devices have support for the basic Greek letters, but not the accented ones.

If you start getting into:

• Unicode 6+ (2010)
  • Versions beyond when the devices were even created.
• Wingdings/Webdings
  • Like the ones I posted here 🙦 🢨 ➫
• Emojis
• Complex Maths
• Rarer spaces
  • See Post #12 and citations in "break/no-break and other spaces".
• Rarer punctuation
  • Like the Interrobang ‽
• Rarer symbols
  • Like the Chi Rho ☧ (I once read a King Arthur book with that in it).
• Asian languages
• More eastern european characters/alphabets

then you'll probably want to start embedding fonts for that.