Quote:
Originally Posted by Notjohn
I spend more time than I should on the KDP forums, and I can testify that the same is true of the vast majority of author-publishers.
|
Not knowing, not caring, not ever looking is a far cry from the author-publisher who's shown an
interest in getting things "right," but doesn't really worry about non-functionality-affecting minutiae like internal file extensions and "perfectly clean" code.
I know how
I want things to look under the hood of epubs
I'm working on, but when it comes to epubs I'm
reading: it's all about the render. Unless I come across something about the way it renders that puts me off my feed (more than trivially), I'm not even going to pop the hood and look at the code. So if someone wants to publish garbage code that manages to render reasonably well on the devices I use ... more power to them. They're not hurting me or their bottom line.
And if it doesn't render well?... then they're only contributing to their own demise. I can fix the garbage on my end (if the content seems worth it). Most others will either deal with the garbage formatting or not buy any more stuff from that author-publisher.
Either way... "clean" ebook code is only relevant to a tiny few (myself included). But it's pretty meaningless in the overall ebook-selling/reading game.
Get it structurally/functionally/visually "right" (or suffer the financial consequences); and let your own conscience dictate how picky you want to be about the rest.
EDIT: But if you DO decide to just "wing it" and let the code fall where it may ... don't then later change your mind and hand your mushtml to someone like Hitch and expect them to fix it for a nickel. By tomorrow morning.