KF7 Image Sizing

[mattmc]

Okay, so a rather mundane problem:

I have a book that I'm starting to QC for KF7, and among the lack of font embedding and lack of right margins, I'm having trouble sizing the images.

The images in my book are generally larger than they need to be, and I've been using CSS to percent-size their width, which works fine on ePub readers and KF8 readers and so on.

For KF7, some cursory googling told me that percentage sizing doesn't work, and I need to size by px. However, changing width:17% to width:50px doesn't seem to do anything--the image still fills my whole K1 screen. I've also tried inlining that CSS on the <img> element, and even just straight-up width="50px" as an old-school attribute. No dice.

The only way I've managed to change the size is by going in and changing the actual size of the image, and I'd rather not do that if possible.

As a note, I've been using Kindle Unpack to rip apart the resultant Mobi, and in the case of the width:... CSS, I couldn't find any resultant attrs on the element.

Does anyone have any advice on this, and particularly any examples of books with CSS-resized images, known to behave correctly on a KF7 reader?

[KevinH]

Old mobi is based on a subset of html 3.2. According to that spec, this is done by adding inline in the image tab a height and width which is always interpreted as pixels.

So try something along the lines of having both

height=100 width=50

as attributes of the img tag.

[mattmc]

Originally Posted by KevinH

Old mobi is based on a subset of html 3.2. According to that spec, this is done by adding inline in the image tab a height and width which is always interpreted as pixels.

So try something along the lines of having both

height=100 width=50

as attributes of the img tag.

Thanks, that's good, precise information of the kind I was looking for. Now, check it out:

I tried using the width and height attributes inline on the <img> tag, and it didn't seem to do anything (on my K1). I tried both increasing and reducing the image size, no dice.

Check out my code, and what it resulted in based on Unpack:

<!-- Original: -->
<h1 class="someClass"><img class="_idGenPageitem-1" src="image/102249.jpg" width="50" height="50" alt=""/></h1>

<!-- Unpacked: -->
<h1 width="0" align="center"><font size="+3" face="Adobe Garamond"><img src="Images/image00851.jpeg" width="50" height="50" alt=""/></font></h1>

So the width/height attrs are actually coming through, at least. Do we know that this works on K1? Any ideas of what else could be wrong?

Thanks!

Edit: Also tried this, with no dice: (no <h1> and all that)

<img align="center" src="Images/image00852.jpeg" width="50" height="50" alt="" />

[KevinH]

Sorry, you have me stumped if your last simple test did not work. Perhaps there is an old mobi guide someplace that might help.

I found this link for the original mobipocket format:

http://www.mobipocket.com/dev/articl...TagRef_OEB.htm

And from it your last test was correct and should have worked.

[Hitch]

Originally Posted by KevinH

Sorry, you have me stumped if your last simple test did not work. Perhaps there is an old mobi guide someplace that might help.

I found this link for the original mobipocket format:

http://www.mobipocket.com/dev/articl...TagRef_OEB.htm

And from it your last test was correct and should have worked.

Kevin:

Don't I recall that the actual K1 devices had this very display bug? I just tested (a variant on this coding) myself, on a K2 yesterday, and it worked fine. I am almost positive that this is a first-gen Kindle issue, like the way that tables won't work on it either.

Anyone else remember this? I no longer have my K1 to confirm.

Hitch

[Notjohn]

So when I'm formatting for images, I should use a media call for KF7 devices with width=?

I've noticed that while the "Kindle" (DX?) view in the emulator ignores my image sizing, the Look Inside sample obeys the instruction.

[Hitch]

Originally Posted by Notjohn

So when I'm formatting for images, I should use a media call for KF7 devices with width=?

I've noticed that while the "Kindle" (DX?) view in the emulator ignores my image sizing, the Look Inside sample obeys the instruction.

NJ:

Not to be pesky, but haven't you repeatedly said that all your images are set to 100%? IOW, if that's true, then...the LI would "obey" it because that's the limiter, anyway, right?

Hitch

[mattmc]

Originally Posted by Hitch

Don't I recall that the actual K1 devices had this very display bug? I just tested (a variant on this coding) myself, on a K2 yesterday, and it worked fine. I am almost positive that this is a first-gen Kindle issue, like the way that tables won't work on it either.

Anyone else remember this? I no longer have my K1 to confirm.

Thanks for helping investigate, Hitch, and good to know it works on a K2.

Although it would be good if anyone else with a K1 could weigh in and confirm it's a bug with the device, I'm going to assume that's the case for now.

I ended up writing a script that finds all images in the book, checks their CSS to see if they're percentage-sized, and if so resizes the actual image to be that percentage of the K1's screen, in pixels (which I've read is roughly 500 or 520 wide).

So then it just is the right size for K1 & K2. My logic is that most devices are roughly that size anyway, and the ones that are smaller would be K4iOS or KDroid on phones, which (correct me if I'm wrong) the percentage CSS would work fine with, shrinking the images to the correct size. The only odd man out would be the original DX, because then you get the image stretching beyond its native size, and some pixellation--but I think I'm willing to live with that.

And, I'm only using that script for my Kindle file, so there are nicer, higher-res images for iPads and stuff like that.

[Hitch]

Originally Posted by mattmc

Thanks for helping investigate, Hitch, and good to know it works on a K2.

Although it would be good if anyone else with a K1 could weigh in and confirm it's a bug with the device, I'm going to assume that's the case for now.

I ended up writing a script that finds all images in the book, checks their CSS to see if they're percentage-sized, and if so resizes the actual image to be that percentage of the K1's screen, in pixels (which I've read is roughly 500 or 520 wide).

So then it just is the right size for K1 & K2. My logic is that most devices are roughly that size anyway, and the ones that are smaller would be K4iOS or KDroid on phones, which (correct me if I'm wrong) the percentage CSS would work fine with, shrinking the images to the correct size. The only odd man out would be the original DX, because then you get the image stretching beyond its native size, and some pixellation--but I think I'm willing to live with that.

And, I'm only using that script for my Kindle file, so there are nicer, higher-res images for iPads and stuff like that.

Matt:

You mean, with the corresponding physical size set in the inline html, right? Not simply with the % set for the KF8 coding in the CSS? I want to be sure we're both saying the same thing.

For KF7, you have to manually (or using your script, whatever) set the physical display size in h/w. If you don't, the images *will* enlarge to 100% of the size of the screen. If I didn't make that clear earlier, my apologies, but I thought I had.

The K1 bug is that no matter what you do in the inline, it displays 100%. (n.b.: it's not actually a bug. The early Kindle design assumed that every image was going to be a cover, and thus--100% of the width of the screen. Offered as a piece of trivia, ASSUMING I'm remembering this correctly. Famous last words.)

Just physically re-sizing an image to be, say, 300px wide won't cause KF7 to display it that way. You have to tell the device that the w=300. Thus, two sets of styling for EVERY image, unless it's intended to always be 100% of the width of the device, regardless.

Hitch

[mattmc]

Originally Posted by Hitch

Matt:

You mean, with the corresponding physical size set in the inline html, right? Not simply with the % set for the KF8 coding in the CSS? I want to be sure we're both saying the same thing.

For KF7, you have to manually (or using your script, whatever) set the physical display size in h/w. If you don't, the images *will* enlarge to 100% of the size of the screen. If I didn't make that clear earlier, my apologies, but I thought I had.

The K1 bug is that no matter what you do in the inline, it displays 100%. (n.b.: it's not actually a bug. The early Kindle design assumed that every image was going to be a cover, and thus--100% of the width of the screen. Offered as a piece of trivia, ASSUMING I'm remembering this correctly. Famous last words.)

Just physically re-sizing an image to be, say, 300px wide won't cause KF7 to display it that way. You have to tell the device that the w=300. Thus, two sets of styling for EVERY image, unless it's intended to always be 100% of the width of the device, regardless.

Hitch

Hm, no, I set the corresponding "physical" size of the file, the image file, using an image processing library in my script.

(If the css is width:50%, and the image is 750px wide compared to the 500px-wide Kindle screen, I would scale it by 0.33 so it's 250px, or 50% of the screen width.)

The actual physical pixel size of the image file seems to be the only thing that affected the display of the image on K1, based on my tests. As I said, the inline width and height attributes were being ignored.

(The only tweak to that statement is if the image is bigger than the screen--then K1 did scale it down to 100% of the screen width.)

I did leave in the % sizing in the CSS for the KF8 version, and I tested that and it looks OK on the Paperwhite and Fire.

Make sense?

-----

Do you know if K2/DX behave this way as well, perchance? You're saying you need to have inline width/height attributes, but maybe it's worth a quick test to see if these devices respect the actual size of the image file, if you have no such attributes?

That's definitely the case on the K1, so if the K2/DX are different and require the width/height attributes, that would just be frustrating. I would have to both resize the image file, and add inline sizing, to get the images displaying correctly on all KF7 readers.

Anyway, as I said, if you have time to test that out I would really appreciate it.

[Hitch]

Originally Posted by mattmc

Hm, no, I set the corresponding "physical" size of the file, the image file, using an image processing library in my script.

(If the css is width:50%, and the image is 750px wide compared to the 500px-wide Kindle screen, I would scale it by 0.33 so it's 250px, or 50% of the screen width.)

The actual physical pixel size of the image file seems to be the only thing that affected the display of the image on K1, based on my tests. As I said, the inline width and height attributes were being ignored.

(The only tweak to that statement is if the image is bigger than the screen--then K1 did scale it down to 100% of the screen width.)

I did leave in the % sizing in the CSS for the KF8 version, and I tested that and it looks OK on the Paperwhite and Fire.

Make sense?

-----

Do you know if K2/DX behave this way as well, perchance? You're saying you need to have inline width/height attributes, but maybe it's worth a quick test to see if these devices respect the actual size of the image file, if you have no such attributes?

That's definitely the case on the K1, so if the K2/DX are different and require the width/height attributes, that would just be frustrating. I would have to both resize the image file, and add inline sizing, to get the images displaying correctly on all KF7 readers.

Anyway, as I said, if you have time to test that out I would really appreciate it.

The K2-->DX family of KF7 devices won't obey the size of the image. I can tell you that without testing. The fact that the image will blow up to the full size of the screen, without any constraining code, is well-established.

The K1 is a very poor testing platform, I'm sorry to tell you. If you test on the DX emulation on the Previewer, you'll have a far more reliable indicator of the vast majority of the devices than using a K1. I can't even imagine where on earth you found one these days, but...{shrug}. The display capabilities/mechanisms of the K1 are not similar to those of the k2-->etc. Without trying to sound remotely snotty, seriously, you can have a K2 in days, if you look around, or a DX, in 1-2 days if you order it from Amazon, and you'll be a lot closer to what you need, than with a first-gen Kindle.

I can absolutely tell you that the only way to get decent image sizing on any image smaller than 100% of the width of the screen is to a) set it using % in KF8 and b) set it using pixels, inline, both height and width, in KF7. That's it. You can do it either with both inline (% and px), or with the % in CSS and the px inline; but it needs to be done.

Test it on the KP. You'll see what I mean.

Hitch

[mattmc]

Originally Posted by Hitch

The K2-->DX family of KF7 devices won't obey the size of the image. I can tell you that without testing. The fact that the image will blow up to the full size of the screen, without any constraining code, is well-established.

The K1 is a very poor testing platform, I'm sorry to tell you. If you test on the DX emulation on the Previewer, you'll have a far more reliable indicator of the vast majority of the devices than using a K1. I can't even imagine where on earth you found one these days, but...{shrug}. The display capabilities/mechanisms of the K1 are not similar to those of the k2-->etc. Without trying to sound remotely snotty, seriously, you can have a K2 in days, if you look around, or a DX, in 1-2 days if you order it from Amazon, and you'll be a lot closer to what you need, than with a first-gen Kindle.

I can absolutely tell you that the only way to get decent image sizing on any image smaller than 100% of the width of the screen is to a) set it using % in KF8 and b) set it using pixels, inline, both height and width, in KF7. That's it. You can do it either with both inline (% and px), or with the % in CSS and the px inline; but it needs to be done.

Test it on the KP. You'll see what I mean.

Hitch

Found my K1 one on eBay, $50

Hm. Okay, so, I caved and ordered a used K2 on Amazon. What the hell, why not?

Next order of business, Kindle Previewer. I'm running the latest KP for OSX, version 2.941. I load in my book and switch to "Kindle DX" mode. Nice, big screen, no embedded fonts, seems like a legit KF7.

So, I made two test files, attached screenshots kf7-image-test-large and kf7-image-test-small.

Both files, when unpacked, have identical KF7 markup:

<h1 height="9%" width="0" align="center"><font size="+3" face="Adobe Garamond"><img src="Images/image00852.jpeg" alt=""/></font></h1>

(Interesting, in some earlier tests I had not seen any height or width inline attributes being created by my CSS, and I'm not adding them by hand...and I wonder at the percentage and the zero in there...)

The images in either version are different sizes, as I put into the actual image, and they're clearly displaying at different sizes. Neither are filling the screen.

(As I said earlier, if the image is bigger than the screen, it'll max out at 100%. But that's not quite what you've been saying.)

Thoughts?

[Hitch]

Originally Posted by mattmc

Found my K1 one on eBay, $50

Hm. Okay, so, I caved and ordered a used K2 on Amazon. What the hell, why not?

Next order of business, Kindle Previewer. I'm running the latest KP for OSX, version 2.941. I load in my book and switch to "Kindle DX" mode. Nice, big screen, no embedded fonts, seems like a legit KF7.

Yes. It is. I use it extensively for a quick check on books; I only slap the files on the "real thing" when I feel a qualm about something. Both the Voyage (KF8) and DX (KF7) are highly reliable previews.

So, I made two test files, attached screenshots kf7-image-test-large and kf7-image-test-small.

Both files, when unpacked, have identical KF7 markup:

<h1 height="9%" width="0" align="center"><font size="+3" face="Adobe Garamond"><img src="Images/image00852.jpeg" alt=""/></font></h1>

(Interesting, in some earlier tests I had not seen any height or width inline attributes being created by my CSS, and I'm not adding them by hand...and I wonder at the percentage and the zero in there...)

The images in either version are different sizes, as I put into the actual image, and they're clearly displaying at different sizes. Neither are filling the screen.

I'm obviously missing something. I don't understand why you have two different files? And why wouldn't the files have identical KF7 markup? Can you please elaborate?

(As I said earlier, if the image is bigger than the screen, it'll max out at 100%. But that's not quite what you've been saying.)

Thoughts?

Yes, I have a bunch. I wonder if we are somehow miscommunicating, or if I'm misunderstanding your intent? I hope you don't mind my questions, to obtain some clarity:

1. Why are the images inside a header? H1, to be precise? I noticed this, I think, earlier, but thought it was anomalous, but here I see it again? Why is this?
2. You have a bunch of mixed instructions here. I see a height instruction of 9%--which is for what? Is that intended to be for the image, or for the heading, that's containing the image?
3. Then there's a font size of "3," which is typical KF7 sizing.
4. My inference is that the heading is being used to constrain the image size. That's what I see--just like using divs to constrain images for iBooks, essentially.
5. The % shouldn't work at all, for this. That should affect the view on a KF8 device, not a KF7, assuming that it's interpreted to be for the heading.

What I've been saying is that you either write something like this:

<img class="90" src="yadda.jpg" height="50" width="XXX">

With the Class defined as being 90% (width or height, your call), or whatever it is you want for that image, in the CSS,

OR, you put the style inline, inside the img tag. Either will make the image work correctly in both KF8 and KF7, but you need to have both. Otherwise, the KF7 simply won't work.

If you try plain old image coding, without putting the image inside a heading, without putting it inside font tags, without putting it inside a paragraph tag, I think you'll see what I mean. You're getting artificial results, more or less, because your images are being put inside other elements, that wouldn't normally hold them, like headings or font tags. You know what I mean?

(You can use Divs to provide constraint for an image, but AGAIN, you still need the KF7 coding for the KF7 devices).

Right?

Hitch

[JSWolf]

delete post

[mattmc]

Originally Posted by Hitch

I'm obviously missing something. I don't understand why you have two different files? And why wouldn't the files have identical KF7 markup? Can you please elaborate?

Sorry; I made two different files with two different sizes of image. I was trying to see if the size of the image file would have any bearing on how big it was displayed on the screen. So I saw that the same markup was produced no matter the size of your image--a logical conclusion, but whatevs.

Originally Posted by Hitch

Yes, I have a bunch. I wonder if we are somehow miscommunicating, or if I'm misunderstanding your intent? I hope you don't mind my questions, to obtain some clarity:

1. Why are the images inside a header? H1, to be precise? I noticed this, I think, earlier, but thought it was anomalous, but here I see it again? Why is this?
2. You have a bunch of mixed instructions here. I see a height instruction of 9%--which is for what? Is that intended to be for the image, or for the heading, that's containing the image?
3. Then there's a font size of "3," which is typical KF7 sizing.
4. My inference is that the heading is being used to constrain the image size. That's what I see--just like using divs to constrain images for iBooks, essentially.
5. The % shouldn't work at all, for this. That should affect the view on a KF8 device, not a KF7, assuming that it's interpreted to be for the heading.

Questions are good; clarity is good

1. The images are inside a header because that's the markup that InDesign generated. No more, no less.
2. Sorry, I was confused earlier and thought that the 9% was on the image, but you're right, it's on the header tag. That was what InDesign generated; I don't know what purpose there is for putting a % height setting on a header.
3. Font size 3, sure. Again, ID-generated.
4. Mayhaps. Again, not intended that way, but maybe that's what's happening. (I am familiar with the iBooks image problem and the workaround.)
5. Interesting, okay. So basically the sizing settings on the header, a % and a zero, aren't doing anything, based on what we know of KF7.

Originally Posted by Hitch

What I've been saying is that you either write something like this:

<img class="90" src="yadda.jpg" height="50" width="XXX">

With the Class defined as being 90% (width or height, your call), or whatever it is you want for that image, in the CSS,

OR, you put the style inline, inside the img tag. Either will make the image work correctly in both KF8 and KF7, but you need to have both. Otherwise, the KF7 simply won't work.

I'm tracking that you would use a class with a % sizing, and that will bear out in the KF8 file. I do have that, and in the KF8 file they are percentage-sized. (I didn't attach pictures of that--it's just the DX Previewer, so just KF7 was shown.)

The part that wasn't working for me was the inline sizing on the img tag. I haven't included any markup examples, but the reason I started this thread was that even setting the width="xx" and height="xx" on the img tag didn't seem to be affecting its size in the KF7 file, at least on my K1 (and the DX Previewer).

Originally Posted by Hitch

If you try plain old image coding, without putting the image inside a heading, without putting it inside font tags, without putting it inside a paragraph tag, I think you'll see what I mean. You're getting artificial results, more or less, because your images are being put inside other elements, that wouldn't normally hold them, like headings or font tags. You know what I mean?

(You can use Divs to provide constraint for an image, but AGAIN, you still need the KF7 coding for the KF7 devices).

Right?

Hitch

The datum you've given me is that, unless you specify a width and height on the img tag itself, it will blow up to 100% of the screen size.

What I'm seeing is that the image is simply being displayed on the screen in the size of the file, regardless of any width or height attributes on the img tag. As you can see from my screenshots, I made 2 files with different sizes of image, with the image sizes painted in the image itself for clarity. And you can see from the screenshots that they're displaying at two different sizes in the DX Previewer.

(It's just different behavior from what you were saying, hence all this. )

So then, you're theorizing that this behavior is because the img tag is within an h1 tag. As we've gone over, the h1 tag isn't even really constrained to any particular size, since the size attributes on it aren't supposed to be applicable to KF7. So the idea is that by simply putting an img tag inside another tag, you can prevent it from expanding to 100% of the screen size...right? (Similar to the ibooks bug, except you don't have to do the 100% width/height on the img, and the explicit size settings on the constraining div/span.)

If that's true, then there's two ways to constrain image sizes on KF7. Remove the img tag from everything and put sizes on it, or stick it in another tag. That would be the conclusion, just two ways to go about it. Next time I'm at my desk I'll pull the sucker out of the h1 tags and see how it looks. Based on what you're saying, it'll explode up to 100% screen size.

Anyway, I hope that I've clarifies? In the end, it just may be that we accidentally found another way to counter a sizing bug on KF7.