would it not better to have some sort of manual so that can be distributed!!
Maybe, but I don't know how to get it actually read, and if it does get read there are people who won't believe it, even though if they tested what that manual says they could see the problems with their own eyes. And there is another class of people (particularly at DP) who are extremely hostile to the idea of small machines and "All I want to do is make beautiful HTML so leave me alone!" -- where "beautiful HTML" actual means "on my 20 inch monitor on my particular operating system running my particular choice of browser." [I could probably be arm-twisted into writing such a manual, but doing so is going to make *some* people at DP very unhappy, whereas others there *are* recognizing these problems and *are* honestly searching for solutions -- which is not trivial given the DP "groupthink" -- as opposed to the PG "groupthink" [where "groupthink" is clearly the wrong word for what is going on on the PG side ;-] If you think about it, HTML really doesn't provide the capabilities to code these issues well. For example on 4" wide machines the customer doesn't want to have body margins set *at all* -- no margin please. Plus the small machines all have margins built into the physical design of the machine, so if you write in HTML margins then you are putting margins inside of margins. Whereas on a 20" monitor you really do want margins, in part because your monitor is much wider than it is high -- and "everybody" agrees that a higher-than-wide format is better for reading. And because the typical web browser isn't designed for reading, it is designed for browsing, and it doesn't have margins designed at all into its design anywhere, so your HTML code without margin sets glyphs smack flush with the edges of the surrounding window frame of the web browser. Okay, so setting a % margin works, right? No it doesn't. 10% margins left and right on a 4" machine still "eats up" 0.8 inches of an already-small real estate which makes the user of the small machine really really unhappy -- in part because the 4" screen is so small justification routines were just barely working to begin with, until you messed with it, and now justification has become really really ugly.
Furthermore, it is nice that they look good on a kindle, but would it not be better if the looked good on other readers as well.
In practice if one can get it to "work" in the Kindles then it will "work" on the other EPUB devices to. [ I was just showing "Kindles" to try to demonstrate to people that "Kindles" are already becoming effectively "epub" machines with the introduction of Kindlegen V2. And "freekindlebooks" is a mobi site not an epub site. [an early decision where I was pushing back against other sites who were pretending to be "all things to all people"]] With the possible exception of really weak "EPUB" readers such as some of the 3rd party epub apps one finds for android, and/or one computer vendor I can think of that has deliberately trashed their implementation of epub to make it really incompatible to try to force authors to target that platform exclusively, and who is now creating tools for that platform with the EULA says "If you use this tool then we own exclusive distribution right to anything you make with this tool [aka 'we own the copyright.']" Again, when we are talking about "Kindles" nowadays there are really two classes of Kindles: There are "legacy" hardware Kindles which are the ones we all know about which cause great grief because they don't support floats and absolute positioning and a bunch of other stuff which really doesn't work on small machines anyway. And there are "modern" Kindles which support KF8 which really is pretty much just epub stuffed into a mobi wrapper. So the "modern" Kindles *are* effectively "epub" devices -- except they take a different file format wrapper. Now the only "modern" hardware Kindle at the moment is Kindle Fire -- but Amazon has been claiming "any day now" they will be releasing updated software for "recent generation" Kindles to make them KF8 ie "epub friendly." [The "software" Kindles such as Kindle for PC, Kindle for Android, etc. update automatically and probably have support for KF8 "epub" already whether their owners know it or not.] [See mobi_unpack.py if you want to check out the claim that KF8 really is "just" "epub"] The major heartache here, well there are two actually, is 1) legacy Kindles don't do floats and DP implements almost all page numbers as floats, and sticks those floats in the middle of paragraphs, so, if the line number isn't allowed to "float" out of position, then the reader gets stuck with reading "trash" page numbers in the middle of their paragraphs exactly where the HTML author put them in the first place. Now, if you think about it, putting page numbers in the middle of paragraphs is a really really bad idea to begin with, doesn't really follow the model of "HTML" to begin with, but, there you have it. And many people at DP and a few at PG are really wedded to the idea of page numbers (I think the "official" position at PG is that "we" don't like page numbers, if anyone looks up the directions to submitters.) [PS: "real" books put page numbers up in the upper right hand or left hand corners of the page where the reader doesn't have to read them. ] [[PPS: epubmaker already throws away common implementations of page numbers when targeting Kindles.]] And 2) the second major heartache is that Kindlegen V2 sticks "both" mobi7 and kf8 in one file for distribution. Now when such gets fed through the Amazon system Amazon says they know the capabilities of the end recipient hardware and strip out the unused component. But serving these from PG this makes a big file even bigger -- unless PG were to turn on compression which is an option for the mobi file format [epub always gets served with compression by definition, since epub is just a zip file format, with the result that PG epub files are much smaller than even the current PG mobi files] And Kindlegen V2 now supports some @media pragmas which would allow PG/DP to fix Kindle-specific problems while maintaining one HTML source code. Given that it usually only takes a half dozen CSS changes [excepting page numbers] to get things "to work" this is maybe not too bad an option. Unfortunately I don't think there are any effective EPUB-specific @media pragmas out there. Some people say "@media handheld" but I *think* the epub hardware community refused that -- being afraid their devices would get stuck in the "mobile version" ghetto with the ancient crusty PDA devices such as Blackberries. PG *could* invent a "@media epub" pragma that epubmaker could chunk on [epubmaker already contains a bunch of these undocumented "pragmatic" hacks] which would allow PG/DP to continue to have one HTML source with a couple little pragmatic sections dedicated to "fixing" things that don't work on the smaller machines. But its not clear to me what things, if any, that PG/DP should be trying to "fix" via epubmaker vs. asking submitters to think about these issues before submitting HTML code to PG. [epubmaker does do other "useful" things to HTML code, such as trying to autogen a TOC, put in a dummy "cover", splitting and repacking the HTML in epub-compatible format, etc. Also it does a lot of rewriting to try to get around the limitations of kindlegen V1 -- not clear to me how much of that rewriting is really necessary to target kindlegen v2 -- But Marcello knows these issues much better than I, having been the one bit.]