Test oeb2mobi output for me?

[llasram]

Originally Posted by llasram

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.

Ah! It's only the 2 (or maybe 3 or 4...?) low bits which are used for the overlap data. Mobigen sets higher bits to mean... er... something else -- and don't I wish I knew what.

[wallcraft]

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.

In addition, the chapter numbers aren't lining up exactly - and some of them have the left side of the first number clipped.

I get the same thing on the EZ Reader (Hanlin V3). The TOC menu item just takes you to the in-lined TOC, and then you follow standard links. With 2 links per TOC entry and the TOC page cuts are not clean. See the 2nd and 3rd attached image (scans of the device). The 1st image shows the cover page, with the bottom obscured by the system footer. This is primarily a limitation of the Hanlin's MOBI image processing, but I think an image smaller than 600x800 would be better (best for the Kindle would be 525x640, although on the Kindle the image is resized automatically). The 4th scan shows the half page left at the start of each Chapter, but the Chapter start looks right.

The last scan is from OpenInkPot (FBReader based), it does not honor the CSS for a chapter start, and the text starts with all caps. In OpenInkPot the TOC works either via following links from the in-lined TOC or by bringing up the TOC menu item and selecting the chapter from a list. This is the same behavior you see with Desktop FBReader.

[tompe]

Originally Posted by kovidgoyal

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

Yes, but the character count is in the raw data and I do not know if there is support for this. I cannot decode it and then count the positions.

[tompe]

Originally Posted by llasram

Ah! It's only the 2 (or maybe 3 or 4...?) low bits which are used for the overlap data. Mobigen sets higher bits to mean... er... something else -- and don't I wish I knew what.

I am waiting for the description on the Wiki before thinking about supporting this

I thought UTF-8 was standardized and could only be done one way...

[kovidgoyal]

Originally Posted by tompe

Yes, but the character count is in the raw data and I do not know if there is support for this. I cannot decode it and then count the positions.

You can still do this (albeit rather inefficiently) by converting to whatever universal encoding you use, then iterating character by character and re-encoding each character into utf-8 to see how many bytes it takes.

[tompe]

How do I create a correct UTF-8 encoded book? Is -unicode to mobigen enough?

[llasram]

Originally Posted by wallcraft

The 1st image shows the cover page, with the bottom obscured by the system footer. This is primarily a limitation of the Hanlin's MOBI image processing, but I think an image smaller than 600x800 would be better (best for the Kindle would be 525x640, although on the Kindle the image is resized automatically).

Mobipocket's developer documentation suggested that 600x800 was optimal, but apparently not then...

Originally Posted by wallcraft

The 4th scan shows the half page left at the start of each Chapter, but the Chapter start looks right.

That's really weird... The chapter headers are created with a 'height="5em"' attribute, which in Mobipocket speak should produce a top margin of only 5 or so lines (Mobi seems to be quite fuzzy on what an "em" means). Is this happening on the Cybook etc too?

Originally Posted by wallcraft

The last scan is from OpenInkPot (FBReader based), it does not honor the CSS for a chapter start, and the text starts with all caps.

Eee -- that bad? There actually isn't any CSS in the mobibook -- just Mobipocket-extended HTML 3.2. If FBReader isn't providing formatting for this then it isn't providing formatting for any HTML content. Nothing at all I can really do there.

[llasram]

Originally Posted by tompe

How do I create a correct UTF-8 encoded book? Is -unicode to mobigen enough?

That's what I've been doing, yah. Although you are correct that it seems to be quite, quite rare. I don't have all that many Mobipocket books, but of the ones I do have only one is built that way (one of the most recent Tor freebies).

[nrapallo]

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.

*Thank you* for finally confirming my suspision that the byte count to the filepos/link is "off" in mobi2html (and consequently in Mobi2IMP). I've had to sometimes add upto 200 extra bytes to find the "anchor" tag the filepos was referring to in my conversions from .prc to .imp. I had no idea why I had to do this and never would have thought the UTF-8 decoding could have precipitated this, but it does make awful good sense to me now that you mentioned this!

My Mobi2IMP solution (which was a brute force naive approach) was to scan forward in the uncompressed text (html) from the stated filepos position and look for the first '<' to plop the anchor (for that filepos)! 99% of the times it worked, but it was not elegant nor foolproof!

[wallcraft]

Originally Posted by llasram

Mobipocket's developer documentation suggested that 600x800 was optimal, but apparently not then...

I agree that is what they suggest, but most EInk devices don't use the full screen for a MOBI image. I'm not sure about the Cybook though.

Originally Posted by llasram

That's really weird... The chapter headers are created with a 'height="5em"' attribute, which in Mobipocket speak should produce a top margin of only 5 or so lines (Mobi seems to be quite fuzzy on what an "em" means). Is this happening on the Cybook etc too?

I don't have a Cybook, but it is happening on the iLiad, see the attached screen shots. It is treating the space as "ems" (smaller space with a smaller font), and part of the problem may be the very wide line spacing used by the Java MobiPocket Reader. However, it looks like there is extra space over 5em.

Originally Posted by llasram

If FBReader isn't providing formatting for this then it isn't providing formatting for any HTML content. Nothing at all I can really do there.

I was not complaining, the only criteria for FBReader is not to cause strange formatting and this is fine.

[wallcraft]

The TOC does not work on the iLiad. It is possible to call up the TOC, but stylus tapping in the "links" does nothing. In a standard TOC this would take you to the chapter.

[nrapallo]

Originally Posted by wallcraft

The TOC does not work on the iLiad. It is possible to call up the TOC, but stylus tapping in the "links" does nothing. In a standard TOC this would take you to the chapter.

Then, is there something wrong with the original .html source or llasram's conversion to .mobi?

@llasram

Can you post your original .html source file used to create this .mobi ebook in post #1? This way we can verify which is the culprit...

[llasram]

Originally Posted by nrapallo

Then, is there something wrong with the original .html source or llasram's conversion to .mobi?

It's definitely my generation code. It may be because the links are in a table? But I'm ditching the CSS-table-as-Mobi-table conversion anyway.

Originally Posted by nrapallo

Can you post your original .html source file used to create this .mobi ebook in post #1?

Sure -- it's my EPUB edition of the The Three Musketeers.

[pdurrant]

The Cybook displays Mobipocket covers at full screen (so 600x800 is good for the covers on a CyBook), but not in-line images. I don't know what the optimum size is for in-line images on a CyBook, and I suspect it could change with new firmware.

Originally Posted by wallcraft

I agree that is what they suggest, but most EInk devices don't use the full screen for a MOBI image. I'm not sure about the Cybook though.

[Jellby]

Originally Posted by pdurrant

The Cybook displays Mobipocket covers at full screen (so 600x800 is good for the covers on a CyBook), but not in-line images. I don't know what the optimum size is for in-line images on a CyBook, and I suspect it could change with new firmware.

I hope new firmwares (or OpenInkpot) will allow to change the margin size and even open an in-line image in full screen. In the meantime, the cybook resizes an image if it's too large, so it's not that bad to have 600x800 in-line images. The usable text block is around 500x650, I'd say...