DOCX to MOBI - Picture Size

[jw-]

I'm hoping to publish my book on Amazon starting next month.

In my book, I have chapter pictures. That is; each chapter starts with a picture above the chapter heading. The pictures are landscape format, and intended to fill the top 40% of the chapter page; i.e. just over 1/3 of the page.

I'm checking the conversion on an Android Phone running Kindle. I also have access to a Kindle Paperwhite.

I'm having trouble getting the pictures to be large on the device. I want it to be edge to edge on the device if possible, or at least 1/3 of the page if possible. I've tried the following:

1. Making the picture very large.
2. Making the picture 72 dpi and 300 dpi
3. Aligning the picture different ways in MW-Word
4. Changing caliber input and output formats
5. changing caliber MOBI output from Old to Both to New. (Both and New don't work on the Kindle, however.)
6. Changing from PNG to JPG format

In my book there are 37 chapters, so the pictures are a big deal. I hate to have them shrunk to a small size when they are such an important part of the book.

I have Sigil. I've heard I might have to format to EPub, use Sigil to replace all 40 pictures, and then... ? That seems a lot of processing.

TIA

[eschwartz]

Have the pictures been compressed (i.e. small filesize and low resolution)?

If so, this may help: https://chrismcmullen.wordpress.com/...e-compression/

[BetterRed]

@jw - have you set Word's options to not resize images. How to do that varies between versions. Suggest you search for "Stop Word nnnn Resizing Pictures".

On Word 2003/2007 changing the settings will only affect new image insertions, any existing images will have to be reinserted. Not sure about 2010/2013.

IMO Word isn't the best authoring tool if the book contains lots of different images and the primary target is a flowable format (eg epub, mobi etc). At it's core Word is a fixed format editor, so it's at its best if you're targeting print or PDF, where resizing images makes sense.

One alternative approach might to insert markers in the text to identify which image goes where, and then replace the markers with the images using an ebook editor, such the calibre ebook-editor or Sigil.

BR

[jw-]

Hey thanks guys! The article helped a lot. I think i found a procedure.

If I use Calibre to convert Word to EPub. Then in EPub I go to Edit, and manually resize the pictures. Then convert to MOBI and send, they turn out right on my unit.

So overall it looks like pixels is the key. I need the pictures to be like 2000 pixels. I'm going to play around further to see if I can convince word to transmit these.


I'll check on a Kindle device.

[jw-]

Ok. I got more info. There are a lot of places that shrink the pictures. Here's what I've found.

1. For size, it is best to go with JPG in the Docx file.
2. Convert from Docx to Epub. For this conversion choose the Default Output file. Not Generic eInk. This will still reduce pictures to no more than 1500px (ie. if you have a Word picure that is 2400px by 2000px, it will go to 1500px)
3. Edit the EPUB. Go to the picture and resize it to 1500 or more.
4. Edit the stylesheet.CSS - Find the entries marked Calibre12 <- with a number. Some of these are text formatting. But most of mine are for the pictures. They start looking like this:

.calibre12 {
display: block;
height: 359pt;
line-height: 1.2;
margin-left: auto;
width: 468pt
}

See the height and width are hard coded. You need to take out those lines. I'm still experimenting whether the other 3 lines are needed.

After this I compile to MOBI. When I view the document, the pictures appear to resize to the page width. Which is what I want.

So it looks like 2 things; 1, get the right Pixels in the Epub, and 2, remove the hardcoded formatting in the stylesheet.css.

Edit: It looks like all the contents of Caliber12 { } can be removed for images. Between that and learning that it is easy to re-size them in the EPUB file, my problem looks to be solved. I checked this on Kindle Paperwhite and on Kindle App on Android.

[JSWolf]

In Calibre, set the output profile for Tablet so the images don't get resized. Also, there is an option someplace in Calibre not to resize the images for Mobi.

[jw-]

JSWolf you are right on with Tablet mode. That saves me a step.

It would really help if you could point out the spot for MOBI. My best option right now is to had edit the CSS file (in 37 places) every time I rebuild the MOBI. I'd love to avoid doing that.

[BetterRed]

Originally Posted by jw-

JSWolf you are right on with Tablet mode. That saves me a step.

It would really help if you could point out the spot for MOBI. My best option right now is to had edit the CSS file (in 37 places) every time I rebuild the MOBI. I'd love to avoid doing that.

@jw - I don't think there is a specific option for suppressing image resize for MOBI, if there were then I would expect it to be in the MOBI Output section of the Conversion dialogue. There is an option there to suppress conversion of images to JPEG, it might be worth 'experimenting' with that.

BR

[jw-]

To follow up further; I find the cleanest conversion is to put the JPG into the Word file. That means that it won't be converted down the line.

Through trial and error I have found the best size is 1400 pixels wide. I've converted all my images to landscape, so they are about 1400x1000 at this point.

I use Calibre to do DOCX to EPUB. Before doing, I set the output format to 'tablet'. This preserves the picture size in the EPUB file.

Then I edit the EPUB. I get into the stylesheet.css and I remove the lines that look like this:

.calibre12 {
display: block;
height: 359pt;
line-height: 1.2;
margin-left: auto;
width: 468pt
}

So they look like this:
.calibre12 {
}

Then I use Calibre to go EPUB to Mobi.

When I send to Kindle on Android, and also to Kindle Paperwhite, the images are on the top 40% of the page, full width. If I turn the unit sideways, the pictures stay the same size (so they must be being sized on the device).

[eschwartz]

You might want to consider importing the DOCX directly into the calibre editor as a new book, since that will not flatten the CSS (unlike a conversion). So stylenames won't be haphazardly run over, which is something to value when you are actually editing the thing.

[jw-]

eschwartz thanks for the idea. It took me a lot of tries to figure out how to import to the editor. what I found was I needed to Edit a file, then select import from Docx, and quit the file I'm in without saving.

When I did this, the CSS looked nice and clean. However, none of my chapters or page breaks imported. So this file would not be right for an eBook.

My book has more than 20 chapters, each with a picture, so it would not look right to have no page breaks.

[eschwartz]

The Import-book-as-DOCX method should not be doing anything different than the DOCX Conversion, except for preserving styles and stuff.

I assume the Chapters are properly referenced within the book, and that a conversion generates the appropriate pagebreaks...

Here's a thought.
The conversion pagebreaks are probably created automatically, using the Structure Detection part of the Conversion process. I don't know if the DOCX Import does Structure Detection.
Now, if the pagebreaks were defined in the DOCX itself, rather than created by calibre conversion (which assumes any Header style with text that contains "Chapter" is... a chapter, and makes a pagebreak) -- then DOCX Import should handle that properly.


Fortunately, you can still use Structure Detection from the editor. Structure Detection uses XPath, and you can probably just copy the value in the Conversion dialog and use it in the editor.

Just right-click in a file and select "Split at multiple locations".

[eschwartz]

Also note that you should be able to associate the editor with any filetypes you want (Windows Explorer ==> Open With). You will have to select the program yourself.

Then you can open the book from Windows Explorer. (calibre>=2.20.0 on Windows 8 will register itself automatically, but DOCX is not on the list of supported formats. See my last comments HERE.)

[jw-]

Yes, my Docx H1 style ensures a leading page break, because I use it for Chapter headings (and also TOC). It's a fault of word that you can't also ensure an odd page, but that's a word issue. For brevity, my chapters contain only the number, and the chapter title, and not the word "chapter".