Different Previews in 2.94 and 3.29

[Doitsu]

Originally Posted by Hitch

I would look to the K2/KKeyboard for a best view of the general appearance on KF7 devices.

Amazon released a firmware update for the Kindle Keyboard, which added, among other things, KF8/AZW3 support.
Of the remaining devices without KF8/AZW3 support the Kindle DX is most likely the only device that is still in use, because of its screen size.

[kso]

@Rubén and @Hitch:

Regarding the DX and other Kf7 devices: am I mistaken in thinking that I don't need to do anything, because images that are wider than the screen are reduced to 100% of the screen width? All the images to be used will be available in sizes matching the current Publishing Guidelines which recommend, I believe, 3200px width, and in the HTML I don't specify width or height in PX.

And @Doitsu: thx for the heads up on the Keyboards' software upgrade. But I'm going to ebay to get one anyway to see images at grayscale. Might find other problems I'm not aware of.

Klaus

[RbnJrg]

Originally Posted by Hitch

Yup, just like the original code to control image sizes in iBooks, remember, Ruben? :-)

Exactly

Mmmmm...the DX is the largest by far, of the KF7's. While I understand your temptation, I would look to the K2/KKeyboard for a best view of the general appearance on KF7 devices. FWIW.

Kkeyboard supports .kf8/.azw3 so the only devices with .kf7 format are Kindle 1, Kindle 2 and Kindle DX but as Kindle 1 doesn't support tables, we can forget to write something for it. And as the DX model is more modern and with a better size, I'd prefer to write the code for it. But of course, is only my opinion and Klaus can do what he want.

[RbnJrg]

Originally Posted by kso

@Rubén and @Hitch:

Regarding the DX and other Kf7 devices: am I mistaken in thinking that I don't need to do anything, because images that are wider than the screen are reduced to 100% of the screen width?

Hmmm, I'm not sure. I don't remember well but with images inside a table things are different. In those cases I think the images could see partially. Maybe Hitch can give you a better answer, more accurate, because I really don't remember well how was the behaviour of an image inside a table cell when the width of the original picture was wider than the screen.

[Hitch]

Originally Posted by RbnJrg

Exactly



Kkeyboard supports .kf8/.azw3 so the only devices with .kf7 format are Kindle 1, Kindle 2 and Kindle DX but as Kindle 1 doesn't support tables, we can forget to write something for it. And as the DX model is more modern and with a better size, I'd prefer to write the code for it. But of course, is only my opinion and Klaus can do what he want.

OMG, I really am getting old--I meant the original KK. LOL, which was KF7, of course, back in them thar olden days.

Originally Posted by RbnJrg

Hmmm, I'm not sure. I don't remember well but with images inside a table things are different. In those cases I think the images could see partially. Maybe Hitch can give you a better answer, more accurate, because I really don't remember well how was the behaviour of an image inside a table cell when the width of the original picture was wider than the screen.

Ruben is right. Inside a table is a whole other kettle of fish. The K1 original doesn't support tables AT ALL; the K2 poorly. When you are inside a table on K2 and go to the next page, all the table formatting is 100% lost, and you have a jumbled mess.

I hate to say this, but I would strongly consider using hidden and mqs to deal with this. Stack your images in a vertical stack, for the KF7s. I mean...what you have now MIGHT work, for the images, for most, albeit not all, KF7 devices, but the captions--maybe.

Y'know...presumably, you've already coded it. Right? And you're testing it on KP 2.94? I've found that KP2.94 is reasonably accurate in DX mode for the KF7s. If you think it works there...then try it. It's quite a bit of work to change all your tables to hidden and rework everything (although, obviously, you can regex a lot of it), so if the 2.94 DX preview looks reasonably good to you...meh, it's probably safe enough. It won't work on the original Kindle or the K2 (reliably), but who knows how many of those are still in circulation?

Hitch

[kso]

The way I've arranged things for now is to use DIVs. For anything that doesn't respond to amzn-kf8 these are just vertically stacked DIVs. But for kf8 devices these DIVs use display:table, display:table-row and display:table-cell. Works beautifully on kf8 just the way I intended all along.

And as the images are all wider than the screens, anything that understands the DIVs as no more than vertically stacked boxes will squeeeeze these images so they fit into the screen width. Says someone who, despite his age, occasionally is still an optimist.

I've seen what seems to be another can of worms in PV 3.29.1 with some images, when the display is set to "Phone". These are floats to one side in a body of text, less than half the screen width and they work as required in tablet form oder PV 2.9 or anywhere else I can remember. Except in PV 3.29.1 some of them don't. Have to check if it's image dimensions, file size or random happenings. But this can wait until it rains.

klaus

[Notjohn]

Originally Posted by kso

Regarding the DX and other Kf7 devices: am I mistaken in thinking that I don't need to do anything, because images that are wider than the screen are reduced to 100% of the screen width? All the images to be used will be available in sizes matching the current Publishing Guidelines which recommend, I believe, 3200px width, and in the HTML I don't specify width or height in PX.

That's certainly been my experience, though with equal certainty I have never uploaded an image 3200 pixels wide! I use 800 pixels as my standard, and I thought Amazon was still recommending 600 pixels.

The problem rather is with smaller images. For example, with my colophon I called for width=12% in the html, and I make sure it's rough 100x100 pixels in actuality. That makes for an enlarged display in the DX display, but it's not unacceptable.

Another thing to watch for is mug shots with text flowing around them. That's not supported in the Look Inside sample, and I suspect not in the early-model Kindles either.

[kso]

@Rubén and @Hitch:

Well, it has rained at last. I looked more into the image question with previewer 3.29.1 and it turns out the problem I noticed there has nothing to do with image size but is triggered by a caption that is larger than the percentage width the image was supposed to be scaled to.

The intent was to have an image floated to one side, about 38% wide, with a caption below, and the copy wrapping around a container holding both the image and caption. Works if I set the display of the PV 3.29.1 to either Tablet or E-Reader. Doesn't reliably when I set it to Phone.

What I've settled on - for now - is to use display:block with a 100% width for the span containing the caption string. Strangely the problem manifests itself only when setting the display to phone.

To verify that the display:table code Rubén provided graciously a while back works on an actual Voyage like display I ebayed myself a Kindle Keyboard as suggested by Hitch. Of course it does. And would you believe it: I actually like the gadget, far more than my Fire, and I have already spent £1.09 to buy a book for it (because it's the last in a series and was never available in print although all the others were). The book was supposed to cost something like four pounds whatever, but Amazon gave me a discount without telling me why. I don't mind the why, but I sure hope they'll continue doing that should I buy more.


@Notjohn:

For images Amazon's Publishing Guidelines (now?) say that you should allow twice the device width of the largest device to allow for zooming into images. That would make that a ginormous width of 3200 pixels. As that'll be scaled down for each device type it's probably not that much of a problem. And in order to have a somewhat comparable layout across devices I use images set to a percentage of the screen width rather than fixed pixel sizes.

I wish there was a reliable resource that has @media query capabilities and screen dimensions for each device. Without that some of the work I'm supposed to do for my daughter is based on experiments and guessing.

But thanks for the heads up about Amazon's "Look Inside" feature, something I've completely overlooked so far. It seems never-ending.


Klaus

[RbnJrg]

Originally Posted by kso

Well, it has rained at last. I looked more into the image question with previewer 3.29.1 and it turns out the problem I noticed there has nothing to do with image size but is triggered by a caption that is larger than the percentage width the image was supposed to be scaled to.

The intent was to have an image floated to one side, about 38% wide, with a caption below, and the copy wrapping around a container holding both the image and caption. Works if I set the display of the PV 3.29.1 to either Tablet or E-Reader. Doesn't reliably when I set it to Phone.

Althought is not recommendable to set the font size in pixels, maybe it could be an alternative in this case specially for smartphones since of that way, fonts won't increase it's size. I mean the text for captions, not all text, just for captions.

[Notjohn]

>For images Amazon's Publishing Guidelines (now?) say that you should allow twice the device width of the largest device to allow for zooming into images.

Thanks! I'll check it out.

>That would make that a ginormous width of 3200 pixels. As that'll be scaled down for each device type it's probably not that much of a problem.

Well, I hope the software that calculates the download size, hence the 15-cent download fee, has been rewritten to make it not much of a problem!

I still have books on the Amazon store that were uploaded with images 450 pixels wide, as instructed on the DTP/KDP platform in the early years, sigh....