Quote:
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.
Quote:
|
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.