MobileRead Forums - View Single Post

ldolse · 06-16-2011, 04:01 AM

Calibre should take either of those examples without a problem.

Calibre's process isn't quite like your initial description. Input and output have no relation to one another.

Calibre takes the input and converts it to OEB.

If you want to see exactly how the conversion to OEB works, step by step, then enable debugging, and look at each stage of conversion in the debug output. The css flattening (what you describe as local styling), happens during part of this stage)

Calibre then takes OEB and converts it to the output format.

OEB is basically unzipped epub, and there are lots of things that epub supports that Mobi doesn't. If you have these sorts of things defined Calibre needs to make best effort decisions on converting such things to mobiml, and those decisions may not always be exactly what you like.

If you start with epub then minimal changes will be made during conversion to OEB (Primarily css flattening).

To get the closest mobi rendering to the original avoid epub features which are unsupported in mobi. The mobipocket docs covers these types of things - mobi hasn't been updated over the years, so any of the old info is still valid. Some of the Kindle's interpretations of MobiML have changed, but that's about it.

A couple items which come up frequently/recently:

Don't use margins in the epub source (or use the ignore margins option during conversion), instead use blockquotes/nested blockquotes - each nested level gets ~1.5em left margin (depends on the kindle firmware)
Right margins are completely unsupported
Avoid any floating/wrap around styles, drop-caps, floating images, etc.
Table border styles aren't supported
Fine grained control of super/subscripts is unsupported

If you have specific suggestions on how a specific type of markup should be converted to MobiML for more accurate conversions then these often get implemented, but no-one is actively trying to improve upon the current level of MobiML output, as the reverse engineering effort is no fun. If you want to see the MobiML that Calibre is producing during conversion, then convert the mobi file back to epub with debugging enabled - the raw mobiml file will be in the debug directory.

06-16-2011, 04:01 AM	#4
ldolse Wizard Posts: 1,337 Karma: 123455 Join Date: Apr 2009 Location: Malaysia Device: PRS-650, iPhone	Calibre should take either of those examples without a problem. Calibre's process isn't quite like your initial description. Input and output have no relation to one another. Calibre takes the input and converts it to OEB. If you want to see exactly how the conversion to OEB works, step by step, then enable debugging, and look at each stage of conversion in the debug output. The css flattening (what you describe as local styling), happens during part of this stage) Calibre then takes OEB and converts it to the output format. OEB is basically unzipped epub, and there are lots of things that epub supports that Mobi doesn't. If you have these sorts of things defined Calibre needs to make best effort decisions on converting such things to mobiml, and those decisions may not always be exactly what you like. If you start with epub then minimal changes will be made during conversion to OEB (Primarily css flattening). To get the closest mobi rendering to the original avoid epub features which are unsupported in mobi. The mobipocket docs covers these types of things - mobi hasn't been updated over the years, so any of the old info is still valid. Some of the Kindle's interpretations of MobiML have changed, but that's about it. A couple items which come up frequently/recently: Don't use margins in the epub source (or use the ignore margins option during conversion), instead use blockquotes/nested blockquotes - each nested level gets ~1.5em left margin (depends on the kindle firmware) Right margins are completely unsupported Avoid any floating/wrap around styles, drop-caps, floating images, etc. Table border styles aren't supported Fine grained control of super/subscripts is unsupported If you have specific suggestions on how a specific type of markup should be converted to MobiML for more accurate conversions then these often get implemented, but no-one is actively trying to improve upon the current level of MobiML output, as the reverse engineering effort is no fun. If you want to see the MobiML that Calibre is producing during conversion, then convert the mobi file back to epub with debugging enabled - the raw mobiml file will be in the debug directory. Last edited by ldolse; 06-16-2011 at 04:07 AM.