Quote:
Originally Posted by Turtle91
That would cut out a great deal of useful features. How about pushing eInk to catch up and support those features instead of hampering progress?? I don't doubt that you think a lot of those features are unnecessary, but that doesn't mean no one wants to use them. I mean, really, how often is strikethrough used in a book... But it would really suck to have to figure out how to create that feature when you REALLY need it to tell the story.
Don't throw the baby out with the bath water...
|
Strikethough would not be an issue on an eInk Reader. So it could stay or be added in. It's silly features that go. One silly feature if the <section> thing in ePub 3. It's not needed at all. It's just excess code that does nothing that the OPF's guide doesn't do. The NAV ToC does nothing useful. The NCX ToC is all that's needed 99.9% of the time and for those rare cases, an inline ToC can be made. some of the new stuff in the metadata of the OPF is excessive and poorly thought out as to the formatting. They changed some of the metadata to be more complex with no benefit at all.
Let's work on useful features for READING. eInk handles that just no problem. Also, standardizing on features of the Reading software would be good as well. So all devices using the same software would all work the same. We could eliminate pet peeves that way. For example, margins. Make it so there are no margins for most of the eBooks except for what's wanted to be offset and the reading software would allow the user to set the margins how it's wanted. make the default fonts with a full extended character set for most cases. There's lots of little things that could be done to make things better overall.