Test oeb2mobi output for me?

[llasram]

I think I'm getting close with oeb2mobi, but I'd like to have some people with actual Mobipocket-supporting devices give a book a test and provide feedback. The output I'm getting now looks pretty good (if I may say so myself) in Mobipocket Desktop and is legible in the Palm version (run under POSE), with the following caveats:

• I'm unsure about the cover and general image file sizes. Mobipocket Desktop seems to display them regardless of file size, while the Palm version seem not to display them, regardless of file size.
• Table support. I'm currently turning CSS tables into Mobipocket tables, but I'm not sure if that's the right thing to do. They seem to look fine when viewed moving forward through the text, but get all smashed together when viewed moving backwards. If the table of contents in the attached book is illegible on most devices, I should probably stick to turning explicit HTML tables into tables, with the option to rasterize.

Thanks in advance!

[tompe]

Originally Posted by llasram

• I'm unsure about the cover and general image file sizes. Mobipocket Desktop seems to display them regardless of file size, while the Palm version seem not to display them, regardless of file size.

The Palm version should display images. They have to be less than 64k and I think they have to be in correct format also. jpg worked if I remember correctly.

[Jellby]

The Cybook has no problem with the cover, and from other files I've tried, it has no problem with images larger than 64kB. It also will resize large images "on the fly" to make them fit in the screen. Other devices may have problems, that's why I'm now uploading illustrated books in two versions, one with the "original" images, and another with images further compressed to take less than 64kB. Also, they have to be in JPG or GIF formats, not in PNG, apparently.

As for the table, the Cybook renders it (but no nested tables, I believe). The problem I see is that it does not cut it at "whole" lines. For instance, in the first page of Contents I see up to the top half of line "12" (but this line is complete in the second page), the third page includes the very top of line "53", and the fourth page has the very bottom of line "52". Nothing is lost, but it's ugly.

Ah... and the "header" line shows the author as "Alexandre Dumas, p& #232;re" (no space after &), I guess it does not like HTML entities there (I regularly use latin1 characters without problems).

[pdurrant]

Images in Mobipocket files need to be under around 63KiB in order to be displayed on Palm versions of the Mobipocket reader.

See http://www.mobipocket.com/dev/articl...ile=images.htm

The author name in the EXTH records uses è for è. This doesn't get displayed correctly in the CyBook library, and it also doesn't get displayed properly in the Desktop Mobipocket Reader properties dialog (right-click/Properties) although it does in the preview I've tested changing this to be encoded as UTF-8, (i.e. hex C3 A8 for è) and this displays correctly in both places in the Desktop reader, and also in the Cybook library display. So I think it would be best to encode all the text in EXTH records as UTF-8, if that's the encoding specified in the MOBI header.

The table of contents displays OK in the Cybook, but it's a bit odd to have two links for each chapter - one of the number and one on the title. It would be better, given the navigation limitations to have either one link covering both, or just a link on the title of each chapter.

In addition, the chapter numbers aren't lining up exactly - and some of them have the left side of the first number clipped. I'm using a non-standard font (Fontin), but I see that Georgia shows the same fault, and Verdana even more - I suspect it's just a table fault - not really enough space for the two numerals and full stop for the higher chapter numbers. This problem doesn't show up in the Windows Desktop reader.

But otherwise, on a brief examination, it seems to be a very nicely formatted and well-formed Mobipocket book. I like the care take on the first paragraph of each chapter, and the indents and (lack of) spacing of other paragraphs.

Are there any particular sections you'd like checked?

[llasram]

Originally Posted by Jellby

The Cybook has no problem with the cover, and from other files I've tried, it has no problem with images larger than 64kB.

Originally Posted by pdurrant

Images in Mobipocket files need to be under around 63KiB in order to be displayed on Palm versions of the Mobipocket reader.

Ah, ok. I thought there was a different size limit for covers, but I probably just missed a warning from mobigen when it couldn't reencode the cover image below 64k. If it's just a PalmOS limitation, then I'll make image file size reduction an option rather than required.

Originally Posted by Jellby

Ah... and the "header" line shows the author as "Alexandre Dumas, p& #232;re" (no space after &), I guess it does not like HTML entities there (I regularly use latin1 characters without problems).

Originally Posted by pdurrant

The author name in the EXTH records uses è for è. This doesn't get displayed correctly in the CyBook library, and it also doesn't get displayed properly in the Desktop Mobipocket Reader properties dialog

Ah, oops. That's my fault, and easily enough fixed.

Originally Posted by pdurrant

The table of contents displays OK in the Cybook, but it's a bit odd to have two links for each chapter - one of the number and one on the title. It would be better, given the navigation limitations to have either one link covering both, or just a link on the title of each chapter.

The reason for the "two links" is that the source mark-up uses the CSS 2 'display: table-row' and 'display: table-cell' to create a virtual table where the <a/> element is a row. In CSS 2 compliant renderers the whole contents line is a single link. The only sane way to handle that sort of thing in Mobipocket markup is alas to reproduces the link in each block-level element the source <a/> elemnt encloses.

Originally Posted by Jellby

As for the table, the Cybook renders it (but no nested tables, I believe). The problem I see is that it does not cut it at "whole" lines. For instance, in the first page of Contents I see up to the top half of line "12" (but this line is complete in the second page), the third page includes the very top of line "53", and the fourth page has the very bottom of line "52". Nothing is lost, but it's ugly.

Eww. Ok, I'll ignore 'display: table-*' then.

Originally Posted by pdurrant

Are there any particular sections you'd like checked?

Other than what I mentioned I mostly just wanted to make sure the file actually worked. Maybe check to make sure the "uncrossable" sections like the footnotes and CC license work properly. And oggle the poetry bits (e.g. in chapter 26), which in the source are formatted entirely with CSS .

[Jellby]

Originally Posted by llasram

And oggle the poetry bits (e.g. in chapter 26), which in the source are formatted entirely with CSS .

I believe mobipocket supports a special <p align="poetry">, where if a line is wrapped, the broken part is right-aligned... but last time I tried it didn't work in the Cybook.

When I code poetry, I do something like:

<P WIDTH="2em">Yew are ther boys of the Empire,</P>
<P WIDTH="4em" HEIGHT="0em">Steady an’ brave an’ trew.</P>
<P WIDTH="2em" HEIGHT="0em">Yew are the wuns</P>
<P WIDTH="4em" HEIGHT="0em">She calls ’er sons</P>
<P WIDTH="2em" HEIGHT="0em">An’ I luv yew.</P>

It's a pain to have a <p></p> for every line, but at least I can control the indent.

[llasram]

Originally Posted by Jellby

It's a pain to have a <p></p> for every line, but at least I can control the indent.

My strategy is somewhat different. The source mark-up uses a combination of 'display' 'block' and 'inline' elements with various margins to produce something that is at least recognizable poetry even with CSS-less rendering. My conversion process turns all 'magin-left' properties of block-level elements in levels of nested <blockquote/> tags and 'margin' properties of inline elements into non-breaking spaces. I need to test it with more mark-up samples, but it works pretty well with what I've thrown at it so far.

Unfortunately, it is still a case of "as close as possible"... Even though I figured out how to do hanging indents in converted markup, the Mobipocket renderer doesn't allow a block with a hanging indent to have a left margin. And yet another quirk of the Mobipocket renderer is that when you have something like <blockquote width="0pt"><font size="2">Text....</font></blockquote> then the second and later lines in the "Text...." are indented less than the first line. This seems to be because <blockquote/> is indenting by "1em" -- so the first line is indented at the default font size, then lines which begin within the <font/> tag are indented at the <font/>-specified font-size.

[nrapallo]

I tried to convert your .mobi creation to .imp using my Mobi2IMP which is based on tompe's mobi2html and extracted a complete, but somewhat corrupt .html. See below .zip.

I also ran Three_Musketeers,_The.mobi through tompe's latest mobi2html and extracted the below .zip for you to see.

The links (filepos) have a problem and there is some corruption in the TOC.

Please check your source .html to make sure they are not so corrupt.

[nrapallo]

Originally Posted by pdurrant

Images in Mobipocket files need to be under around 63KiB in order to be displayed on Palm versions of the Mobipocket reader.

(and not personally addressed to pdurrant {the messenger...})

[RANT]

Why wouldn't a mobi2mobi with the gen3imagefix take care of the image size restrictions for those users that need to use PDA's to display ebooks. I think the larger size can easily be "downconverted" to the 63K image size restricted version, thereby, only necessitating one .mobi upload.

Is there any reason to still cater to PDA users (sorry, but my Sony TH55 has never been my main ebook viewer).

[/RANT]

[llasram]

Originally Posted by nrapallo

Please check your source .html to make sure they are not so corrupt.

The issue with the links is a detail of the way I'm generating beginning-of-file links in oeb2mobi. The Mobipocket renderers seem to handle them fine, but I'll make sure it generates something Mobiperl's mobi2html can handle cleanly.

[llasram]

Originally Posted by llasram

The issue with the links is a detail of the way I'm generating beginning-of-file links in oeb2mobi. The Mobipocket renderers seem to handle them fine, but I'll make sure it generates something Mobiperl's mobi2html can handle cleanly.

Actually, I take it back. The Mobiperl 'mobi2html' errors with the Mobipocket book I've generated appear to be errors with Mobiperl's handling of UTF-8 encoded books. With UTF-8 encoding, each text record is followed by 0 or more "overlapping" bytes finishing the current multibyte character, plus an 8-bit integer count of the overlapping bytes as an additional byte. These additional bytes are not counted as part of the content length for the purposes of computing the "filepos" of link targets.

[tompe]

Originally Posted by llasram

Actually, I take it back. The Mobiperl 'mobi2html' errors with the Mobipocket book I've generated appear to be errors with Mobiperl's handling of UTF-8 encoded books. With UTF-8 encoding, each text record is followed by 0 or more "overlapping" bytes finishing the current multibyte character, plus an 8-bit integer count of the overlapping bytes as an additional byte. These additional bytes are not counted as part of the content length for the purposes of computing the "filepos" of link targets.

Well, UTF-8 encoded books does not seem to be so common so I have not noticed this before. Why use UTF-8 and not entities?

Coding UTF-8 or other character set related things is probably the most boring thing I know. When I started using computers there was problem with Swedish characters and ISO 8859-1 support in programs. It is so depressing to have similar kind of problems 25 years later...

[kovidgoyal]

Originally Posted by tompe

Well, UTF-8 encoded books does not seem to be so common so I have not noticed this before. Why use UTF-8 and not entities?

Coding UTF-8 or other character set related things is probably the most boring thing I know. When I started using computers there was problem with Swedish characters and ISO 8859-1 support in programs. It is so depressing to have similar kind of problems 25 years later...

You shouldn't need to do anything codec related directly. Surely Perl has builtin codecs for coding/decoding UTF-8, etc?

[DaleDe]

Originally Posted by tompe

Well, UTF-8 encoded books does not seem to be so common so I have not noticed this before. Why use UTF-8 and not entities?

Coding UTF-8 or other character set related things is probably the most boring thing I know. When I started using computers there was problem with Swedish characters and ISO 8859-1 support in programs. It is so depressing to have similar kind of problems 25 years later...

Well, if that depresses you then you must really be depressed by the recent Zune fiasco. How long have we known about leap year? It was present in the Julian calendar in 70 bce!

Dale

[llasram]

Originally Posted by tompe

Well, UTF-8 encoded books does not seem to be so common so I have not noticed this before. Why use UTF-8 and not entities?

I might... I was just trying to implement support for this in Calibre's mobi2oeb (which doesn't have it either ) and I realized that I don't have the description of what it's doing quiiiite right. Ugh.