Problem with images from epub to mobi

[taskforsome]

Hi all,

I recently converted an epub (which validates through epubcheck without problems) to mobi with Kindle Previewer.

I used relative percentages in the <img> tags, but mobi format resizes all images to fit the whole width of the screen. In the original epub I have the following code for the images:

<div>
<p class="image"><img src="xxx"/></p>
<p class="caption">Caption text</p>
</div>

The problem is that in mobi the image and the caption are not together; in the most cases the image resize to fit screen (width or height) and the caption appears in the next page alone.

How could I resolve that?

Thanks

[dwig]

Originally Posted by taskforsome

...
I used relative percentages in the <img> tags,...
...but mobi format resizes all images to fit the whole width of the screen.

Wrong. "mobi format" is not doing this. Your chosen converter, KindleGen (via Previewer), is doing it.

If you want to use KindleGen for the conversion you should spec each image with the desired pixel size for width and height explicitly, inside of the <img> tag itself.

The problem is that in mobi the image and the caption are not together...

There is no good way to prevent this. No matter what you do, a text caption may render on the next screen when the image is too near the bottom of a screen. You can use a good image editor and create images with "text" for the caption in the image itself. This fixes the current issue, but prevents the reader from scaling the "text" larger or smaller when the user alters their device's base font size. My edition of "The Atlantic River" uses this technique. Most captions are fine in the regular text flow, but some readers may need to "click" on the images to display them full screen (Kindle version only) to make the caption text more readable.

[DiapDealer]

I've only ever had consistent luck controlling image size (using Kindlegen/Kindle Previewer) when I hard-code the sizes in the image tag:
<img src="../Images/my_picture.gif" height="120px" width="80px" />

EDIT: just as dwig said while i was fat-fingering my response.

[taskforsome]

Thanks dwig and DiapDealer.

So, if I undrestood you both well, it is no possible to assign a fluid with to images with Kindlegen, isn't it?

[DiapDealer]

Originally Posted by taskforsome

Thanks dwig and DiapDealer.

So, if I undrestood you both well, it is no possible to assign a fluid with to images with Kindlegen, isn't it?

Across all devices, no. If you know you'll be designing an ebook specifically for the Kindle Fire (and anything else that suports the KF8 format) you can specify CSS image width and height attributes. But if one is a fixed percentage, the other needs to be set to auto in order to preserve the aspect ratio of the image.

You should be able to jump through some hoops and specify the width, height attributes (in pixels) in the (x)html for the normal eInk kindle devices, and then override those html attributes with a CSS media query that would only apply to devices that support the KF8 format (like the Kindle Fire).

@media amzn-kf8 {
  img.myclass {width:80%; height:auto}
}

Kindlegen 2 will ignore that css when building the normal mobi portion, but should use the CSS (that should override html attributes) to style images of the class "myclass" when building the KF8 portion.

I say should be possible because that's the way I'm interpreting the new Kindle Publishing Guidelines. I've not tested that case specifically, but I know the media queries can be used to specify different CSS for different devices. And CSS is supposed to take precedence over html attributes.

I apologize if that was more information than you were looking for.

[taskforsome]

Thanks, DiapDealer. There's never too much information...

Then I wonder if I could apply your suggestion in the ebooks I'm making. I design the original for epub, so I use fluid width for all images: the result is valid in ADE, for example, or in my Sony PRS-T1.

But my client wants to convert these epubs in mobi in order to sell them in Amazon. We've decided not to change the original epub (inserting fixed measures for images), but, according to your comments, it'd be possible to insert a media query for KF8 supported devices, isn't it?

And another question: it'd be possible to maintain image and caption together (in .mobi format) using tables, for example? Or another resoruce...

[DiapDealer]

Originally Posted by taskforsome

But my client wants to convert these epubs in mobi in order to sell them in Amazon. We've decided not to change the original epub (inserting fixed measures for images), but, according to your comments, it'd be possible to insert a media query for KF8 supported devices, isn't it?

Absolutely. I tend to use completely separate CSS files for epub/mobi/KF8. That way, I can use a "master" css file to import the relevant stylesheet. I can then comment out the Amazon stuff (and remove the extraneous css files(s) if necessary) when supplying an ePub... and vice versa when building a mobi.

In the main css file (that every html page links to):

@import url(../Styles/epub.css);
/* @import url(../Styles/mobi.css) amzn-mobi;
@import url(../Styles/epub.css) amzn-kf8; */

I can then comment out the first line and uncomment the next two when building the MOBI with kindlegen.

Originally Posted by taskforsome

And another question: it'd be possible to maintain image and caption together (in .mobi format) using tables, for example? Or another resoruce...

I'm not sure. That's always going to be an issue in reflowable documents. Fixed-Layout KF8's can place captions directly on an image, but I don't think you can mix and match: an ebook is either Fixed-Layout or reflowable. Tables may work, but with MOBIs, bad things tend to happen when tables are used to achieve a certain "layout." Tables should only really be used when you have tabular data to present. Users can often easily "break" table layouts by increasing font-sizes (when they contain text).

[taskforsome]

Thanks again.

A last question. Which are the most common differences/elements in order to be considered in MOBI format? I mean, like the trouble with images...

[DaleDe]

Originally Posted by taskforsome

Thanks again.

A last question. Which are the most common differences/elements in order to be considered in MOBI format? I mean, like the trouble with images...

The other problem you will likely have is with CSS statements. Mobi format does not support CSS at all, nada. The conversion programs will attempt to convert some CSS into something that mobi will understand but it can be spotty and the results may not look like what you expected. KindleGen tends to be better at converting CSS than is MobiPocket Creator.

The ePub specific toc file will be used by KindleGen to create the chapter marks on the progress bar but not to create the Mobi specific TOC. It will need to be created separately. MobiPocket Creator can make this by identifying the rule used to create it such as all h1, h2 headers.

[DiapDealer]

In keeping with the above mentioned CSS conversion issues:

If you're trying to maintain one unified document for ePub and MOBI, keep in mind that kindlegen's css conversion logic can't cope with more than one class being assigned to a single element. so...

<p class="first-class second-class">text here</p>

just won't work.

Something like:

<p class="first-class"><span class="second-class">text here</span></p>

will have a much better chance of being successfully converted to mobi (while still being valid for ePub). Or you could combine the attributes of the two classes into one if possible. Just don't plan on being able to "stack" CSS classes to achieve your desired effect (Note: the KF8 format has no such limitation).