Easy fix for Chapter Problem

If you create a Table of Contents in Word [or rather have Word do it FOR you] it gets translated into a fully linked TOC in Kindle.

However because of a "nesting" issue and Kindle "rendering on the run" [unlike a normal web page], if the reader clicks on a Chapter in the TOC they get taken to the Chapter but without the proper chapter heading formatting.

This can be corrected by going back a page and then forward but that is a bit shonky.

To fix properly you need to put the a name tag before the <h1> tag, but that becomes very tedious for 20 chapters or more.

But you can use Search and Replace to do this in a flash in NotePad or NotePad++ [where you can better still write a macro which you can use for all your format jobs].

Here is a picture of a simple Search and Replace in NotePad

Remember to start from the top of the file.  It inserts a second <h1> after the a name details and to be totally correct you would get rid of the other one, but Kindle does not seem to mind a double start for <h1> but only one </h1>.  Up to you.

If you are brave and use Replace All it should say [as a cross check] "Replaced x instances" which should be the number of chapters in the book, but in case things go wrong I would first do a Save As .... just in case it can't be reversed.

Posting a Utube

Here is an example of how to post a Utube video [yours or others'] at your blog.

Just goto share under the video.

Click on Embed

Copy the code

Paste it here

Clearing the Air about width/height Attributes

 We recently posted the blog 2 below this one understanding-resize-vs-scaling regarding the new Scaling algorithms in Kindle for PC that "do their best" to eliminate white spaces at the bottom of a page by "squeezing" an image in via Scaling.

We made the "aside comment" that, as distinct from a normal web browser, Kindle asks the author to simply tab the image, without any "forced" scaling [because Kindle Browser will be doing all manner of scaling itself, as we see NINE different renditions in the post below].

The comment we made was "In general web authors display an image on a website at full size, and sure way to do that is just specify the image [img src=...] without any attributes, eg width=x height=y." 

That "aside comment" created an extraordinary response at the Kindle Forum from one of the "established publishers"

"I really, really, REALLY do not want to "get into it" with you, but your blog post is completely, utterly, inescapably, WRONG. Height and Width attributes for images absolutely work in html in Kindle. We use them EVERY BLOODY DAY. Honestly, it is MIND-BOGGLING to me that you come here and serve up all this misinformation. What is the point of all this codswallop? WHY do you do this? WHY do you deliberately mislead all these poor DIY newbies? It's CRUEL, and it's a rotten thing to do. I honestly don't know if you are malicious or just ignorant. Either way, it's a crappy thing to do to the noobs." 

We replied that she MIGHT use them every bloody day but, as seen by these posts, Kindle simply does its own thing Scaling wise. The main issue was we had not used any height/width attributes for the subject exercise.

We are still totally mystified by WHY she would use them or in fact why it is such an issue with her. Then we remembered that in preparing our Bible on Word to Kindle we had in fact tried the normal [incorrect] path of inserting images in Word and not in the html.

We uploaded the Word doc and downloaded the html at the Preview. So we went back to that file and here it is in EasyHTML with html at top and browser output below

As you can see [the dark blue], KindleGen took our image graphics2.jpg  and made its own cut down image [at about 80% compression] and saved it in a new directory called images, and finally used ATTRIBUTES of align and border, BUT NO WIDTH OR HEIGHT.

So we hope this clears up the confusion of our friend so she might rejoin her normal life style and heart's ease.

Amazon Kindle has Unbelievable Tekkers

I guess only those Pommy and Oz fans of Soccer AM will understand Unbelievable Tekkers. "Some Tekkers are GOOOOOD Some Tekkers are BAAAAAD then there are UNBELIEVABLE TEKKERS

What is UNBELIEVABLE follows from last post where it seemed Amazon/Kindle browser [at least in the format of Kindle for PC] SCALED at 3 different rates in order to NOT have a White Space at the bottom of a Kindle Page.

We have now gone back to our generic SANDBOX ["where's the playground Suzi?"] and experimented further to find that this SCALING has NINE graduations.

Please observe here using the same image from the book. The author supplied this image [as a 3:4 "MegaPixel Monster] at 1944 x 2592 pixels. We then RESISED it as 400 wide [maintaining aspect ratio].

We also transferred the text in the Word file into a caption ON the image. So what we uploaded to Kindle was simply a 400 x 533 jpg at 90% compression and 80 kb, meaning KindleGen did NOT alter it in any way, albeit it DID SCALE it, and here's the proof.

Here it is with pagebreak before

Up to Line4 no scaling happens. The image simply slides down the page UN scaled.

At this stage you will see that SCALING is starting to take over, ie rather than shunting image to next page it has been reduced in size in order to fit ON the page.

Please scroll down the page to see how this is repeated NINE TIMES as the image is continually made smaller in order to fit what is left of the page.

Finally after 15 lines it gives up on the SCALING and kicks the image into the next Kindle page.

Understanding RESIZE vs SCALING

It is important to understand the difference between Resize and Scaling for websites in general, but then to understand that Scaling in Kindle is different again.

In general web authors display an image on a website at full size, and sure way to do that is just specify the image [img src=...] without any attributes, eg width=x height=y. However if you do specify the exact same size as image, the page opens in a far more orderly manner as "placeholders" open first and images form in that space, albeit fast broadband these days means a well designed webpage opens instantly in either case.

Generally it would be stupid to specify an image say 800 wide and put an attribute of width=200 because the image would be SCALED to 200 but the browser would still have to download an image about 16 times too big for no good reason. However in some cases the site may say right click on this image [scaled to 200] in order to download direct the full size image at 800. In such a case the scaled image is essentially a Thumbnail.

 ***

IMPORTANT SIDE ISSUE RE PPI/DPI

In essence this is exactly the situation that confuses people so much with images in Word.  Your PC screen is probably set at 96 ppi, but let's round it off to 100 ppi.  Word is a Word Processor and is therefore designed to produce PRINT output, and modern printers can produce high resolution prints.  So lets set our printer as 400 dpi [DOTS/inch] so the 800 wide image will measure 2 inches when printed.

So Word does all that by SCALING the image to 200 wide ON YOUR SCREEN, meaning it is displayed at 100 ppi but Scaled to 25% size.

Now the big problem is if one simply saves the Word file as html [filtered or unfiltered], the conversion simply sees the Scaled image so it goes into Kindle as 200 wide.  That is why Amazon says to insert images into the html and NOT the Word file, but seems most folk are not listening.

***

BUT Amazon web site uses lots of different sized "Thumbnails" and these are NOT Scaled but are Resized [using a script or macro] from the image you uploaded. You can see that via right click and Properties. By Resizing, search pages and the like come up instantly because of the small file sizes.

But once we get to Kindle html, the author has no say at all in scaling, ie the width/height attributes in html code DO NOT WORK. Of course there is very good reason for that as it allows the Kindle "browsers" to scale [usually down but sometimes up] in order to make images fit pages in an orderly [flowing] manner. This behavior even differs from device to device.

But just recently we noticed what appears to be a new Scaling feature to remove those nasty white spaces when an image does not fit under text at the top of a page. Please observe this photo with page break before it.





This is displayed at about full size [images are all 400 wide] on Kindle for PC and any text under it would be moved to the next page.  And vice versa WAS the case if there were say 2 lines of text at TOP of page, ie image would be moved to next page.

But now look at this image

With about one third of the page being used for text, Kindle has decided to Scale the image [to about 66%] to KEEP it on the page.

Then when we thought that must be the end of Scaling, please observe this situation.

So text was taking up more than HALF the page but Kindle decided to Scale our image down to about 50%.

As you can see this was not what we wanted as the text we layered ON the image could not be read.  Therefore as Amazon gets more and more clever with its browser algorithms, authors will need to properly proof their books [as an actual azw file, not the nasty Preview at upload] and use page breaks in order to prevent such Scaling.  In this case we were happy to go with image scaled to 66% even though it was smaller than the others, but the 50% Scaled image was not acceptable.