A Comparison of format limitations based on The Hobbit

[Jellby]

Originally Posted by wallcraft

Screenshots of a song. If the PDF (last screenshot) is the definitive version, then none of the others center the text or offset far enough but they all look ok. I'm not good enough at recognizing fonts to tell if these are all using true italics or not. The eReader version again seems to have a transcription error - an extra empty line in the last verse.

I don't think any e-book format allows centering a structured block (like a poem) without giving it a hard-coded width. As for the "true italics", they are usually recognized in the shape of letters like "a" or "f", the italic "a" usually lacks the top curl of the roman "a", and the italic "f" tipically has a descender.

[All4Fun]

Originally Posted by starrigger

I bought the .LIT version of The Hobbit from fictionwise and ran it through convertlit, then Calibre, to produce an epub and a lrf version. Both worked well. The lrf looks a little better on my 700, except that the menu-generated TOC had an odd quirk of showing all chapters twice, first just with chapter numbers, then again with titles. That was a LRF produced from the EPUB. I ran it again, this time producing the LRF from the zip. Better, in that this time the list of chapters without titles in the TOC comes after the list of chapters with titles, and is less in the way. (I suppose there's some setting I could use to prevent that from happening.) The chapter heads look better in this LRF version than in the EPUB.

Why did you not look to purchase the epub version from Books on Board or Harper Collins directly that you know is immediately formatted and compatible with the PRS-700 or convert to lrf if desired?

[JSWolf]

Originally Posted by wallcraft

Two images had the same problem reported in gets SVG when should be JPG. Not surprising since this is in the same series. The Calibre Viewer gives a blank page, but any2mobi returns a greatly magnified small section of the image.

Two other images are converted to 278KB and 550KB jpegs (the ePub originals are 778KB and 1574KB). These show up when I view the MOBI in FBReader, but don't display in Windows MobiPocket Reader. So the images must still be too large to work properly in a MOBI file.

The solution is to edit the two cover HTML files and replace the SVG code with HTML image code. Center the images and Calibre will then handle them fine.

[Godzil]

Originally Posted by SpiderMatt

It seems ePub is the best choice. A lot of people seem to have some minor gripes with each format but at least with ePub, you only have to strip the DRM and editing the book to your liking is a simple task. It looks like running the LIT file through convertLIT has the same effect, actually. The images, at least, are the same size. Can anyone attest to the formatting being the same?

In fact LIT is more like ePub 1.0 and actual ePub is LIT 2.0 (or some sort of)

They both are based on the same basis, made by the same group : http://www.openebook.org/ that made OEB which was used by Microsoft for the LIT format, they since release a new version of their recommendations and it is the ePub format.

[wallcraft]

Originally Posted by SpiderMatt

Can anyone attest to the formatting being the same?

The ePub and LIT versions are almost identical. The CSS is the same, except for very minor changes, and the HTML is the same except for how color is handled for the chapter headings and how some punctuation is done (with actual UTF-8 characters in the ePub and with "&#XXXX;" in the LIT).

[pilotbob]

Originally Posted by Godzil

I you read in the right order,

Oh... I'm sorry. I guess I don't know how to read a forum topic. Thanks for setting me straight.

BOb

[Godzil]

Originally Posted by pilotbob

Oh... I'm sorry. I guess I don't know how to read a forum topic. Thanks for setting me straight.

BOb

Sorry if you find my post offensive, it wasn't what I want. Maybe I should more use the quote function on this forum, for *me* it was obvious that I answer to the post above mine.

[pilotbob]

Originally Posted by Godzil

Sorry if you find my post offensive it wasn't the goal. Maybe I should more use the quote function on this forum, for *me* it was obvious that I answer to the post above mine.

I was being a bit tongue in cheek. Nothing anyone says on a forum really bothers me. However, yes a quote would always help. Also, please just quote a small part of the message.

That said, in the time you were writing your post, 5 other people could have posted, so your post might not be the very next one.

BOb

[hudson]

Originally Posted by netseeker

We made an poll on this within the german sub-forum some weeks ago because we were unsure if we should include "text-align: justify" in the ePubs we are publishing here at MR. The overwhelming majority of the participants seem to prefer justificated text.

I prefer justified text if it is done right. I use LaTeX to typeset all of the documents for my iLiad and Sony to take advantage of the superior algorithms and research that goes into proper line breaking and justification. These include avoiding rivers, avoiding excessive word splitting, proper hyphenation, and microtype optimizations to create optically better alignment.

The naive greedy algorithms used by most of the formats produces a definitely sub-standard layout. It is not as bad on wide screens like the iLiad, but as the page width shrinks to Sony PRS-505 sizes, the rivers of whitespace become unreadable. Why more programs don't use Knuth and Plass' algorithms has always puzzled me.

[netseeker]

Originally Posted by hudson

I prefer justified text if it is done right. I use LaTeX to typeset all of the documents for my iLiad and Sony to take advantage of the superior algorithms and research that goes into proper line breaking and justification. These include avoiding rivers, avoiding excessive word splitting, proper hyphenation, and microtype optimizations to create optically better alignment.

The naive greedy algorithms used by most of the formats produces a definitely sub-standard layout. It is not as bad on wide screens like the iLiad, but as the page width shrinks to Sony PRS-505 sizes, the rivers of whitespace become unreadable. Why more programs don't use Knuth and Plass' algorithms has always puzzled me.

Yes your are right. Imho especially the alghorithm used on Sonys PRS devices for LRF-books acts very strange. I can't say exactly whether it's line based or paragraph based, but sometimes it uses a horrible alghorithm for calculating the badness factor (based on your post i guess you now what badness means in association with such alghorithms).

But even Knuth and Pass' is "only" paragraph-based rather than page-based (agreed it is indeeed far better than most of the alternates).

To be honest we just can't compare and fix differences in the justification for four, sometimes five, different formats on multiple devices for each ebook we create. We uploaders create those ebooks in our spare-time. We use proper hyphenation and avoid excessive word splitting (or we are trying hard to do so) and the ebooks here at MR are usually better formatted than most of the commercial ebooks.

[Jellby]

Originally Posted by hudson

These include avoiding rivers, avoiding excessive word splitting, proper hyphenation, and microtype optimizations to create optically better alignment.

I don't think there's anything in (La)TeX to avoid rivers, other than a human operator checking the output and maybe tweaking the parameters. For the rest, I agree.

The naive greedy algorithms used by most of the formats produces a definitely sub-standard layout.

I agree too, but the algorithms are implemented by the reader software. I doubt the formats have any specification for the line-breaking algorithm. In principle, an e-book reader program could use a TeX-like breaking algorithm, and would give definitely better output.

[hudson]

Originally Posted by Jellby

I don't think there's anything in (La)TeX to avoid rivers, other than a human operator checking the output and maybe tweaking the parameters.

I believe that you're correct that it does not directly address rivers, although the Knuth/Plass algorithm will seek to minimize the amount of additional white space ("glue") per line, which will help reduce rivers.

I agree too, but the algorithms are implemented by the reader software. I doubt the formats have any specification for the line-breaking algorithm. In principle, an e-book reader program could use a TeX-like breaking algorithm, and would give definitely better output.

According to Wikipedia, the only tool other than TeX that implements KP justification is Adobe Indesign*. I'd love to see some of the reader software implement something better than first-fit, although given the slow CPUs in devices like the Sony, re-paginating would be incredibly painful.

*: Although fmt(1) and Perl's Text::Reflow both support it, too.

[IceHand]

Originally Posted by hudson

According to Wikipedia, the only tool other than TeX that implements KP justification is Adobe Indesign*. I'd love to see some of the reader software implement something better than first-fit, although given the slow CPUs in devices like the Sony, re-paginating would be incredibly painful.

Isn't FBReader using the algorithm too?

[Sweetpea]

Hmm, these comparisons don't make it easier for me...

Do I buy the mobipocket one, which I can read without doing anything, or the microsoft reader one, which does have the larger images, but I must reformat first...

[JSWolf]

Originally Posted by Sweetpea

Hmm, these comparisons don't make it easier for me...

Do I buy the mobipocket one, which I can read without doing anything, or the microsoft reader one, which does have the larger images, but I must reformat first...

If you can strip the DRM from the MS Reader version, then Calibre can do a good job converting to Mobipocket and you'll be happier in the long run when you have a better source for the day you get a reader with a larger screen.