jim said:

http://www.idpf.org/ is the source of the descriptions of what EPUB is and what the file format can and cannot do, if anyone actually cares to try to actually figure it all out. It would be a gift to the PG community if anyone can come up with even a simple tool that reliably takes even one HTML file and correctly and reliably following all the IDPF rules convert that HTML into an EPUB that even begins to work on most EPUB machines.

jim is confused. don't let jim confuse you. the .epub file-format is a _specification_.... in other words, it's a blueprint, not a building. the i.d.p.f. -- an organization of corporate publishing houses -- designed this file-format as much to _retard_ e-books as to promote them. that is to say that it is a bad blueprint... because of this underlying agenda of sabotage, they have never provided the world at large with _reference_implementations_, which are programs that _prove_ that the file-format works correctly... for an e-book file-format, you should provide reference implementations for a viewer-app and an authoring tool, if you want a format to succeed. i.d.p.f. never provided either for their file-format. this means that every entity that wants to "support" the .epub file-format has to start apps from scratch. and at ambiguous points, they must make their own decisions about which fork in the road they will take. because of the difficulty and the ambiguity of .epub, the viewer-apps have been hung up with problems... and each app has gotten hung up at a different place, and taken different paths to get there, with the result being that all of these viewer-apps are inconsistent... they are inconsistent with the spec, and with each other. indeed, sometimes the same viewer-app is inconsistent across its own _versions_, so a workaround that solved a problem in version 1.1 _causes_ a problem in v1.2... it's a nightmare. and that nightmare was _caused_ by i.d.p.f. and the .epub file-format. _intentionally_. in fact, one of the biggest embarrassments is adobe, who is a _member_ of the i.d.p.f., and their _major_ tech organization. their viewer-program is so lame that it cannot handle chunks bigger than 300k, so a person creating an e-book has to chop up the text into bite-sized pieces so the adobe app can gum it... so it's a pipe-dream to think that you can implement a single .epub file that works reliably on all machines. and that is _because_ of .epub, not in spite of it...

It is NOT as simple as hacking an existing EPUB and inserting your unmangled HTML into the zip file -- as anyone who has tried this approach on non-trivial HTML files has found.

it's curious that when jim is arguing in support of .html, it's because .html is a common, well-understood format, and it serves as the basis for both .epub and .mobi files... but then jim turns around and tells keith that .html is this monster of complexity, and so is the creation of .epubs... and jim seems not to even realize he contradicts himself. at any rate, let us attack this bug-bear one more time, ok? because jim, let me tell you, as i did before, that you are walking into the same trap sprung on my detractors before. when they were attacking z.m.l., one line of argument was that z.m.l. couldn't handle complex books. this attack was presented repeatedly, day after day, month after month, for _years_, until they became totally and completely convinced it was the absolute truth. for a long time, i played possum, and declined to mount a counter. then, when the time came, i asked a question -- "can you show me some such books?" they had no answer. so it was _my_ turn to pound, and i did, asking them repeatedly for examples they could not provide. needless to say, jim, but the jig is up now, even if i _did_ feel like stringing you along for a long time, which i don't. i played them as fools, getting them to bet their credibility, which they did, and subsequently lost. but you have none to begin with, so there's no fun in playing poker with you. so i will cut directly to the chase. if there is _any_ truth to your argument about "non-trivial" books that i cannot handle with my tool-set, point to them. if we assume there are 20,000 non-duplicate e-books in the p.g. library, and the "non-trivial" ones constitute 30%, then there will be 6,000 non-trivial books. so if you find just 30% of _those_, you could point to some 1,800 books. so let's start very small, ok, jim, and point me to just _18_. i'm waiting, jim. you've kept me waiting a lot, lately, jim...

Is there already such a tool on the internet?  Not that I've found -- and god knows I've gone looking.

as i told all of you earlier, if you really need a program to help you create .epub files, backchannel me and i will point you to one that typically does a pretty darn good job. oh, and there's always calibre as well. it does a good job too, in spite of what jim says about it. he always blames his tools. because that's what poor carpenters do... -bowerbird