And the documentation is definitely still present, but contains no information on LIT-the-archive-format, which is what I was referring to.

I did mention that the reader was a large part of why things looked so good. In fact, I have posted here before that I think MS did a fine job with their ebook reader software and much of what they did should be emulated.

As for the Lit archive itself, I did not say it was a Zip, I said it was similar, but used different compression. I didn’t see the need to bog down this discussion in technical details. Don’t assume that just because I used a simple analogy that I don’t know more of the specifics.

>There’s no LIT-specific documentation available that I know of

I don’t currently have copies, but a few years back I found three different documents on the MS site that detailed Lit and the MS extensions, as well as recommendations on how best to format a Lit ebook. I don’t know if it is still available, but such documentation certainly does exist.

***blinks***

Most of what makes LIT files look good is in how the renderer renders the OEBPS 1.0 markup contained in the LIT archive, but it is certainly not a ZIP archive or anything close. It’s an MS-specific archive format which contains many many bells and whistles to help renderers do things like quickly start rendering from any arbitrary point in the book and render arbitrarily long streams. This is why e.g. LIT on PocketPC has no 300k stream maximum like the Sony Reader version of AdobeDE has for EPUB files.

There’s no LIT-specific documentation available that I know of, but LIT is an extension of the ITOL/ITLS format, which you can find quite a bit about. The LIT extensions which have been reverse engineered are expressed code-wise in the calibre LIT extraction and generation code. (I’ll get around to writing up some documentation at some point…)

Using ‘display:table’ is unconventional, and should have the same effect as the more conventional ‘display:block’ Even better semantically would be to just use a series of block elements for each line of the poem.

This is one of the main problems with everyone using DE as a litmus test for layouts. Many EPUB reading systems are now either based on Webkit, Gecko or cross-platform browser rendering engines. These are well-documented and familiar to frameworks and developers, so it reduces the amount of guesswork in how layouts will perform.

It’s still a mystery what engine DE uses, and therein lies the problem. If Adobe could document the quirks and bugs of the internal document rendering system of DE, we’d all be a lot better off. It’s probably a derivative of the limited engined used by the Flash Player, but I’m not sure. Peter, is developer documentation on the roadmap for DE?

if you look at lit you will see that it’s a lot simpler and based on the older web standards.

Theres this myth that the code behind the web have become simpler and more rigid this is actually not the case the standards have been adopted to allow every hack and nonconformist behavior, epub is born in the new ago of non restrictive spcifications while lit was born back when standards were simpler to implement but did not support anything everyone wanted.

the basic jar like container is the same and the old html4.0strict with css used in lit is for the most part embedded in the much much more complex xhtml1.1 with css2.1 but lit is OEB complient in the same way that ASCII is UTF-8 complient.

Thanks,
David

>>>I just finished an informal test, using Moriah’s epub. ADE does the best job displaying it, followed by FBReader,

What FBReader? I D/Led the one available and it couldn’t do the Pro Abyss. I gave it mine and everything was crap.

Now if THIS Comment goes to Electron Hell, Teleread has seen the last of me in Comments, goddammit.

In my experience, very good results can be achieved by using semantic (or semi-semantic) mark-up and transforming it into EPUB mechanically. This way, a layout expert can create and tweak a template and an author/editor can concentrate on the content. I have experimented with DocBook, Wiki and FB2, I expect TEI would work well too. An “authoring tool” there would mostly be code that you can tweak to match your needs, not some sort of shrink-wrap software. Is there interest in doing something like that? What kind of input formats are interesting?
Doing WYSIWYG is more problematic, but can also work if you use styles rather than on-the-spot formatting. I do not think pure WYSIWYG tools for EPUB would work well for serious authoring. For a “casual publisher” I expect Buzzword will evolve into a practical EPUB authoring solution.

LIT isn’t enough on its own for an ePub subset that is known to work well, but it might be a starting point for such a subset.

Meanwhile big thanks to Peter Sorotokin for not sweeping ADE’s CSS 2.1 problem under the rug. I’m confident that a fix will be on the way when practical.

On another topic, I continue to hope that Adobe can come up with some lower-cost and easier solutions for e-book creation than its current ones. Any thoughts on this, Peter? Rootin’ for some good things to happen.

Thanks,
David

I’m not sure how those examples showing the poetry were marked up but, I’ve had no problems so far when I implement the same feature.

I still get the impression that people are trying to do pixel perfect layouts. People had the same layout challenges with web design back in the early 2000’s, it still happens now, although I think most designers have come to terms with the differences between print and web.

Creating beautifully formatted eBooks is great when they are read on the desktop, but what happens when you throw the thing at an iPhone — we can’t possibly expect to keep that same layout.

For example, epub supports font embedding. Comparing with the PDF version, the epub would be greatly enhanced if you used the same fonts you used in the PDF.

I didn’t know that until tonight when Mike Cane informed me that his pro Abyss copy had an embedded font. Doesn’t that make it bulky? I’ll work on that, though. It would be nice to match the PDF.

You may also want to use another creation tool for the type of control you want to achieve. Calibre is fine for the average user who wants to convert ebooks between one format and another. I don’t think it is suited as a publishing tool for getting professional results.

Well, and that’s the problem I was in a fash about all weekend long. I have eCub but apparently haven’t given it a fair shake since I tried to put an HTML doc through it before I knew better. I downloaded both OO and eScape, but I haven’t gotten around to that, either.

I use WordPad for my markup.

Awesome insights and thank you. I really appreciate it.

I just finished an informal test, using Moriah’s epub. ADE does the best job displaying it, followed by FBReader, then Azardi R2 and dead last is Stanza (Windows).

The two surprises to me were FBReader and Azardi. FBReader has come a long way with epub support. It still has a ways to go, but the recent versions are substantially better with epub. I am surprised that Azardi displayed things worse than FBReader, given its reason for being (a strict, compliant epub renderer).

A few comments to Moriah: You don’t seem to be taking full advantage of what you can do with epub. For example, epub supports font embedding. Comparing with the PDF version, the epub would be greatly enhanced if you used the same fonts you used in the PDF.

You may also want to use another creation tool for the type of control you want to achieve. Calibre is fine for the average user who wants to convert ebooks between one format and another. I don’t think it is suited as a publishing tool for getting professional results.

I can’t comment on InDesign, as I can’t afford it (unless someone wants to give me a copy). You might try that eScape plugin for Open Office (I haven’t gotten around to that yet), or even markup things with a text editor. It isn’t very hard. Notepad++ is a good text editor for this type of thing.

div.poem { display: table; margin-left: auto; margin-right: auto; }

The problem is that the div which is styled as table contains only blocks, not table-rows. CSS 2.1 requires renderer to create implicit table rows and cells in this case, but it does not work right in Digital Editions.

BTW, “margin-left: auto; margin-right: auto;” is not an EPUB-compliant way of centering the content, since OPS explicitly allows “auto” to be treated as 0 (section 3.3).

Obviously I don’t know much of the history behind the LIT, but I DO know that as both a producer and consumer, the production tool is easy sleazy and the product is beautiful to look at (and easy on the eyes).

Joseph,

Personally, I think that the current epub spec left too much as “recommended” instead of “required”. In a later version of the spec, hopefully this will change.

From your fingers to God’s ears.