OK, but this demonstrates, once again, the on-going conflict (with Jeroen's being one common point of view) Jeroen says basically "I want to write HTML for large desktop computer displays, not HTML for EPUB or MOBI on small displays. In fact, *I* want to pick and choose which customers PG gets to support with my efforts. By doing this I can format more conveniently and attractively by optimizing for the large desktop computer displays." PG says (explicitly and implicitly, via their postings) "We want to support not just HTML on large desktop computer displays, but as well as on the small ebook reader devices, including both the EPUB and the MOBI file formats. We want to support ALL customers, not just some of them." These are explicitly mutually exclusive goals, and when PG tries to accommodate both goals at once, then epubmaker gets sent on a fool's errand, and the PG end customer sees formatting bugs in the EPUB and MOBI file formats which prevent the PG books from being read in a reasonable manner on those small machines. And it ends up making PG look foolish, and further, then others simply take the PG code, strip out most or all of that "gratuitous" HTML formatting optimized for large displays, retaining (if you are lucky) <i> and <b>, and redistribute that reduced formatting effort from other locations having removed the PG name. PG Customers want to read in EPUB and MOBI. HTML which is intentionally -- as Jeroen's example describes -- written for large desktop displays will not run correctly on EPUB and MOBI devices. The current PG approach does not resolve this dilemma. PG says formatters are supposed to be submitting HTML that is "write once read everywhere," but in practice PG doesn't enforce that requirement. There are many ways to resolve this problem. One would be to actually enforce the requirement that the HTML be "write once read everywhere." One would be to allow volunteers to directly submit EPUB, and not require that the EPUB and MOBI be derived from HTML. One would be to allow volunteers to submit two versions of HTML, one optimized for the big desktop displays, and another for the small EPUB and MOBI displays. Another would be to allow submitters at submission time to say "This HTML is designed only to work on large desktop displays." Then either you take an approach where PG simply doesn't try to generate the EPUB or the MOBI, or you take the approach where PG ignores the HTML and tries instead to generated EPUB and MOBI directly from the submitted txt files. But then in either case, I think you will find the problem again that all that happens is that other volunteers step up to the bat, rework the HTML to work on the small EPUB and MOBI displays, take out the PG name, and distribute the book via other forums. And then PG customers are left searching around the web to find a copy of the "PG" book which actually works on their EPUB or MOBI devices. In which case, again, why not simply allow these "fixed" versions for EPUB and MOBI be distributed via PG in the first place ???