Jim, I've been using Sigil to make my EPUBs and I'm pretty happy with it. It is also free. You can import pretty much any HTML page and it will convert it into XHTML on the fly. About the only thing it can't do is create links in your pages, but if your pages have links before you do the import the links will be corrected when you split the page into multiple files, rename pages, etc. It will occasionally give a paragraph more than one style class, which kindlegen doesn't like, so you may have to drop into HTML mode to fix that. On the whole, a reaklly well done tool for e-book makers. James Simmons On Tue, Dec 13, 2011 at 8:44 AM, Jim Adcock <jimad@msn.com> wrote:

In a desire to inflict injury upon myself, I downloaded this thing and tried it. What I tested, and what I found is:

I started by downloading a recent HTML from PG "at random" directly into MS Word using the url as the "file name" in Word so that Word would know where to load the images from -- this happened to be the latest "Princess from Mars" with images. To my somewhat surprise Word was happy to accept a url and loaded the entire html document including images.

I then saved this in docx format.

Using the Aspose addin (30 day free trial) I then converted this docx into an epub.

To my great surprise it [somewhat] "worked." The only apparent rendering problem I see is that the "Princess from Mars" float-right page numbers end up being somewhat super-imposed on top of the text that one is suppose to be reading (but please read my previous comments about just how much I think page numbers are a "good idea" in the first place ;-)

Renaming this epub to princess.zip and unpacking it what I see is:

The addin violates typical sane-assumptions about epub by packing "all" the html into one 630 kB file, where for best compatibility they should be following epub recommendations to limit individual file sizes to, what is it? 300 kB?

The generated html is about the same quality of crappiness as Word generated HTML "filtered" -- probably a bit worse than this actually -- with <span> instructions at random every sentence and a half or so, I don't understand why they are doing this, which keep trying to reset the font to the identical color and size.

I have no idea what this thing costs after the 30 day trial runs out.

In summary, it might be useful for people who want a quick and dirty way to SR their HTML in progress on a epub device, but I would hate for anyone to send this quality of epub or html to either PG or archive.org

As an alternative one can try to get Marcello's epubmaker running on a Windoze machine, which is somewhat of a pain, but once you do so you can actually see more-or-less how your code is going to look after being submitted to PG before submitting it to PG -- so if you're poking yourself in the eye at least you'll know it.

_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

On Tue, December 13, 2011 12:52 pm, Jim Adcock wrote:

James >I've been using Sigil to make my EPUBs and I'm pretty happy with it.

I've looked at the code Sigil has generated in the past and I don't remember being overwhelmingly happy with it. One characteristic I would want in the epub editor is that it not change code that I haven't asked it to edit.

My dissatisfaction with Sigil is the primary reason I started working on ePubEditor. There is a bias both at the W3C HTML working group and the ePub working group to force all styling into style sheets. Academically I can't fault this approach, but practically there are any number of older User Agents (and Kindle/MobiPocket falls into this category) that simply do not do CSS well. I've done a lot of experimentation with using CSS programmatically, and I can say that it is harder than in looks. I understand why these User Agents don't satisfy all the requirements.. My approach to HTML in e-books is to try and make a book look good without using styles and without abusing HTML tags. This is how the e-book will look in the least-capable User Agents. I then add styles as an external style sheet that will make the e-book look really sharp /in my opinion/. Believe it or not, I do not believe that my opinion is the only one that counts. By using an external style sheet I hopefully make it easy for anyone to substitute their opinion for mine. I find it hard to remember the specific issues, but Sigil makes it hard for me to use the approach I have found best. On Tue, December 13, 2011 6:38 am, Jim Adcock wrote:

My claim is that it is generally really not necessary to exercise all the excesses of HTML nor all the shortcomings in the ereaders in order to create high-quality transcriptions of most of the books that are out there. I think the real problem is the tendency of all of us to try to "prove" we are uber-geeks leads many to try to out-geek all the others when it comes to the complexity of the HTML code being submitted.

This is very perceptive, and I think explains the drawback of Sigil. It is designed specifically to satisfy the most rigid, strict, and current ePub specification. Thus, some of the things it does makes it inconvenient when you're dealing with some of the less-capable User Agents. I think it was Einstein who said, "make everything as simple as possible, but no simpler." BowerBird's s.m.l. is an example of making things simpler than possible; it is unable to capture the required complexity, and cannot be extended if more complex structures are encountered. Sigil's XHTML is an example of not simplifying enough.