KF7 Image Sizing

[Hitch]

Originally Posted by mattmc

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.

Ok, good--I thought I was missing something.

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.

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.)

OK, good on the KF8. On the INDD tags--I suspect that that is the result of the Kindlegen plugin. It's attempting to compensate by creating HTML upon which KF7 (mobi) can interpret, as KF7 doesn't, presumably, use CSS at ALL.

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).

This is the part that's weird. The K1, I understand; the DX, I don't. I just, just just tested this--to see if the newer software updates had done anything, and they hadn't. Mayhaps (I thought I was the only person who still used that word, mind you. GMTA) it's because of the coding I saw with the 0 for one of the dimensions? Despite the Formatting Guidelines' destructions to set one of the dimensions to "automatic," for this specific purpose--sizing in KF7--our experience is that you require both h and w. (FWIW).

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.

Yes. AND in any other environment, e.g., K4PC, etc. (Assuming that you didn't have suitable KF8 coding, of course).

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.

I admit, I haven't tested this in about a billion e-reader years. (5 or 6 or thereabouts in human years). It never worked previously, and I never saw anything to indicate that it had changed. BUT: none of your tests, so far, have been with naked image tags, right? They've all been embedded inside some OTHER element, that may be constraining them, yes?

(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.

Yes. Lacking any other evidence or credible explanation, yup.

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.

No, but...hmmmm. I wonder if the font=3 is somehow setting the fontsize for the header? Using font in "size" numbers is an oldschool trick for KF7. Just a thought.

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.)

That's sorta what I'm thinking, as I can't otherwise explain what I'm seeing, and given that INDD output (oish), which is a bit indecipherable for we poor mortals, that's my best idea right now.

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.

Anything is possible. We use all sorts of "stumbled upon this due to error" tricks in forcing MOBI and KF8 to perform. Not everything in Kindle is straightforward, and worse, it changes constantly. I mean, constantly. What works today may not work tomorrow (often). Suffice to say, the interpreter doesn't always interpret the same, which is an endless frustration, particularly for those of us using some type of programmatic aid above and beyond clips (we use a PERL script inhouse that one of our bookmakers wrote a while back for cleaning, for example). It's one of the reasons that the formatting can't really be as automated as one would like.

So: let's get you some naked image tags, and work outwards from there, and see what happens.

Hitch