Different Previews in 2.94 and 3.29

[kso]

Hi Folks

I could do with some kind(le) help. I'm working towards the publication of my daughter's book which'll contain a large number of images (optimised to keep the weight down). I'll be using the same HTML structures for web promo, EPUB and Kindle, and only slightly modified CSS for the three.

The result is that everything looks the way I want it to. Well, almost.

Web browsers (Webkit, Blink, Gecko), EPUB, iBook (iPhone and iPad), and the Kindle App on iOS (going through Kindlegen 2.9 for the mobi, and Kindle Previewer 2.94 to build an AZK file sideloaded onto iOS devices), Kindle 4 PC 1.25.1 are all perfect. If I sideload the mobi to my Kindle Fire, it's good too.

Having both the previewer 2.94 and 3.29 I have an issue. I can have good previews (in Previewer 2.94) for the three Fires and the Kindle DX, plus (in Previewer 3.29 with "Enhanced Typesetting") everything that that offers, but not for the Kindle Voyage preview in 2.94. Or I can have everything in the Previewer 2.94 but total crap in 3.29.

Now I don't know how relevant 2.94 previews are today to the hardware out there. Can I assume that all but the very oldest Kindles have had software upgrades*) so that the only relevant previews would be those from the current (3.29) previewer? Or are there still enough Voyages around that won't be updated to the wonders of Enhanced Typesetting and thus require a different approach?

I've tried a few @media queries, but the don't bite in the previewer 2.94.

klaus

*) I can't tell, because my own Fire is on a lan behind a proxy (long story) so it never talks to Amazon. I use it for development work only anyway, as I still prefer dead tree books to reading on screen. There, I've admitted it.

[jhowell]

There are still plenty of older kindles around. I would aim for it looking at least readable on those.

What are you changing in the book to make it go between working nicely in one case or the other?

A screenshot or more detailed description would help. “Total crap” is hard to diagnose.

[Hitch]

Originally Posted by jhowell

There are still plenty of older kindles around. I would aim for it looking at least readable on those.

What are you changing in the book to make it go between working nicely in one case or the other?

A screenshot or more detailed description would help. “Total crap” is hard to diagnose.

Ditto. Let's see what you feel is "total crap" for the eInks, and I would note that the Voyage preview is certainly NOT for old devices. I find the 2.9x previewer quite accurate vis: what I see on my (updated) PPW and Voyage devices--so, post some screenshots, and let's see the issues.

Hitch

[kso]

Ok, let me rephrase "total crap" in my OP to "using a very liberal artistic license".

I have two different sets of CSS instructions, let's call one "old" and the other one "new". The old code doesn't use anything fancy or tricky and is based on best practice on the web. The new one uses work-arounds for things the previewer 3.29 can't (yet?) do, namely floating elements within a container in two different directions.

The old code shows what I expect everywhere except in the Previewer 3.29.

The new code displays as expected in the previewer 2.9 for all devices but the Voyage, plus in 3.29 (I haven't tested the new code any web browser or EPUB reader because the current (old) one works and I fear the new code is fragile).

What I'm trying to do is to have an image gallery showing two images in a row*), one occupying about two thirds of the width, the other one a third with a tiny gap in between. I alternate large and small from left to right to liven things up.

To do this I have a DIV (the row) spanning the total width, with two DIVs inside as container for the images plus optional caption. The inner DIVs are scaled to percentages of the row DIV. The images are scaled to 100% width of the inner DIV with the height set to "auto" to keep the aspect ratio. No magic involved.

See screen shots below (I had to use two images for the oldcss 3.29 preview to show the clearly how the page is formed).

Now, and this is the reason why it took me a while to reply, I had an idea this morning. Because the effect seen on the new CSS code Voyage image, that the smaller image is tucked into to the top right corner of the large one when (and only then) the large image is positioned left and the smaller one should be on the right, I asked myself: what happens, if I use the new CSS code, and set both widths to one half of the available space.

Bingo - ish.

With 50:50 and no gap, and 49%, 2% gap and another 49%, the CSS is interpreted correctly and the images are scaled and positioned the way they should be.

Same for 48-2-50, 47-2-51, 46-2-52 and so on ... all the way to 42-2-56, which fails.

Which leads me to believe this is a bug in the 2.9 previewer using freedom of expression when parsing numeric values. I tried reducing the gap in between, which didn't make any difference

Now the question really boils down to: is the preview for the Voyage 2.9 correct or just a fluke.

@Hitch: I see from your remark that you have a Voyage. If I upload a small sample mobi would you be able to load this onto your Voyage and see where the smoke comes out?

Thanks

Klaus

*) on Phones and tiny devices images are shown just stacked vertically.

[Hitch]

Originally Posted by kso

Ok, let me rephrase "total crap" in my OP to "using a very liberal artistic license".

I have two different sets of CSS instructions, let's call one "old" and the other one "new". The old code doesn't use anything fancy or tricky and is based on best practice on the web. The new one uses work-arounds for things the previewer 3.29 can't (yet?) do, namely floating elements within a container in two different directions.

The old code shows what I expect everywhere except in the Previewer 3.29.

The new code displays as expected in the previewer 2.9 for all devices but the Voyage, plus in 3.29 (I haven't tested the new code any web browser or EPUB reader because the current (old) one works and I fear the new code is fragile).

What I'm trying to do is to have an image gallery showing two images in a row*), one occupying about two thirds of the width, the other one a third with a tiny gap in between. I alternate large and small from left to right to liven things up.

To do this I have a DIV (the row) spanning the total width, with two DIVs inside as container for the images plus optional caption. The inner DIVs are scaled to percentages of the row DIV. The images are scaled to 100% width of the inner DIV with the height set to "auto" to keep the aspect ratio. No magic involved.

See screen shots below (I had to use two images for the oldcss 3.29 preview to show the clearly how the page is formed).

Now, and this is the reason why it took me a while to reply, I had an idea this morning. Because the effect seen on the new CSS code Voyage image, that the smaller image is tucked into to the top right corner of the large one when (and only then) the large image is positioned left and the smaller one should be on the right, I asked myself: what happens, if I use the new CSS code, and set both widths to one half of the available space.

Bingo - ish.

With 50:50 and no gap, and 49%, 2% gap and another 49%, the CSS is interpreted correctly and the images are scaled and positioned the way they should be.

Same for 48-2-50, 47-2-51, 46-2-52 and so on ... all the way to 42-2-56, which fails.

Which leads me to believe this is a bug in the 2.9 previewer using freedom of expression when parsing numeric values. I tried reducing the gap in between, which didn't make any difference

Now the question really boils down to: is the preview for the Voyage 2.9 correct or just a fluke.

@Hitch: I see from your remark that you have a Voyage. If I upload a small sample mobi would you be able to load this onto your Voyage and see where the smoke comes out?

Thanks

Klaus

*) on Phones and tiny devices images are shown just stacked vertically.

A couple of things:

1. yes, I have a Voyage and a PPW and if you want me to look at it, sure.
2. Unfortunately, CSS/HTML that is "best practices on the web" has absolutely nothing whatsoever to do with what works in eBooks. Unfortunately, CSS/HTML that is "best practices on the web" has absolutely nothing whatsoever to do with what works in eBooks. The set of HTML/CSSS that works in eBooks is quite proscribed, compared to HTML/CSS for the Net.
3. What you have here is going to be utterly trashed, on the KF7 devices. It won't work, at all. Did you notice that, in the DX view? That the images didn't do what you expected?
4. I also suspect it will crash and burn on Kindle Cloud Reader, too.
5. Lastly, the PPW family of devices has had a bug, for forever, in which images that are >50% of the width of the screen will ALWAYS enlarge to 100% of the screen. If you see that behavior in the 2.9x Previewer, it's not a bug in Previewer. It's how the devices have worked since the jump.

If you want to load a file, go right ahead, but, typically, this is done with a table. Sorry to be the bearer of bad tidings, but...web HTML is typically far, far, too advanced for the Kindleverse. (Like "keep together" coding. Nope, doesn't work, either.)

Hitch

[kso]

Originally Posted by Hitch

A couple of things:

What you have here is going to be utterly trashed, on the KF7 devices. It won't work, at all. Did you notice that, in the DX view? That the images didn't do what you expected?

I noticed in the DX preview that _some_ images are off to the right by some as yet unidentified text-indent, whereas others are full width. Have to compare the code around both groups.

Originally Posted by Hitch

I also suspect it will crash and burn on Kindle Cloud Reader, too.

When I tried that some time ago it was a not-for-Linux thing, but now I have windows (in a VM) I'll try again.

Originally Posted by Hitch

Lastly, the PPW family of devices has had a bug, for forever, in which images that are >50% of the width of the screen will ALWAYS enlarge to 100% of the screen. If you see that behavior in the 2.9x Previewer, it's not a bug in Previewer. It's how the devices have worked since the jump.

That explains exactly what I'm seeing, and it takes away a lot of job satisfaction. Damn. I did read - somewhere - that when working on Kindle output, to not try anything sophisticated. Had to see it to believe it though.

Thanks for looking into this.

Klaus

[Hitch]

Originally Posted by kso

I noticed in the DX preview ...(snippage for brevity)

That explains exactly what I'm seeing, and it takes away a lot of job satisfaction. Damn. I did read - somewhere - that when working on Kindle output, to not try anything sophisticated. Had to see it to believe it though.

Thanks for looking into this.

Klaus

You bet. I'm sorry to be the one to tell you all this, but...now you see why poor old working slobs like me and my guys use tables, for layout beyond simple vertical stacks. SORRY!! I know what it's like, all too well, to put in a lot of time and effort on a great layout, only to have it not work out.

Hitch

[kso]

Originally Posted by Hitch

...

SORRY!! I know what it's like, all too well, to put in a lot of time and effort on a great layout, only to have it not work out.

Hitch

And that after I've been so very close. It's only the voyage preview that's not right. And maybe some silly bits occasionally, when a figure's caption is shoved to top of the next page, but they can probably be worked around or through.

At least it's Friday evening.

Klaus

[jhowell]

I suggest that you also try out the larger and smaller font sizes in your book if you have not already done so. Many of us with not so perfect vision rely on the ability to choose the font and font size that works best for us.

[RbnJrg]

Originally Posted by Hitch

...but, typically, this is done with a table.

I was going to say the same. Except for Kindle 1 (the very very old model), the code should work for any Kindle device. Unless you want to use "fancy code" (by using your words) for the .kf8/.KFX formats and to use the properties "display: table"; "display: table-row"; "display: table-cell". I say that because the format .KFX still has issues to handle tables and if you want to enable "enhanced typesetting" maybe could consider to use those properties (of course, also you'll have to write code with tables for K7 models). But if you are not interested in "enhanced typesetting", then just use tables for all.

[kso]

I shall have to give tables (older devices) and display:table-cell etc (kf8++) some serious thought, and some experimentation. The final product should have "Enhanced Typesetting" as having the attribute is almost as important as some real typesetting, so it'll require additional coding.

In a way it's funny; last time I used tables for layout was about 20 years ago. Not sure if I find the time this week though, but at least I have some hope now

thanks for pointing me in the right direction.

Klaus

[Hitch]

Originally Posted by kso

I shall have to give tables (older devices) and display:table-cell etc (kf8++) some serious thought, and some experimentation. The final product should have "Enhanced Typesetting" as having the attribute is almost as important as some real typesetting, so it'll require additional coding.

In a way it's funny; last time I used tables for layout was about 20 years ago. Not sure if I find the time this week though, but at least I have some hope now

thanks for pointing me in the right direction.

Klaus

Sure, Klaus:

And be a BIT careful with tables, too. There's an undocumented issue with tables--if you have some that are too long, or too many (I think the current number is 58?), your ET will also be turned off. I can't remember, senile old bat that I am, if I already mentioned this, but...you have to be a bit careful with tables, too, I'm sad to say.

Hitch

[kso]

Well, what a lovely way to spend a Sunday morning.

Tables, as suggested by Hitch, or display:table (row, cell) as suggested by RbnJrg, do not work in my case. As soon as one of the images in a row is set to be a slightly more than 50% of the column width, bang, up it blows to 100% width, and the other one is squashed like a bean stalk and, listen to this, shoved into the margin beside the table (if you ever need to position something in the margin, you now know how it's done).

Did some more media query hunting and came across some really weird ones. Not having a Voyage I'm not sure if they work on the actual device, but in both the previewers they give me hope. And a little wonderment. Some of the queries try to isolate the Voyage by resulution. The DX in Previewer 2.9 reports two different Voyage/Oasis resolutions on the same page (1448 by 1072 and 1440 by 1080) and believes that one Fire query applies to it as well. If I select Voyage in the PV 2.9, it too has two different resolutions (same pixel count as before).

And the three Fires in PV2.9 also believe to have both Voyage resolutions. The Previewer 3.29.1 reports the same values as PV 2.9 does for the tree Fires. Same goes when I open the mobi in Kindle 4 PC.

My own Fire thinks it's a kf8, not a mobi, and selects the "fireall" query from github without also claiming to have one or both of the Voyage resolutions. That what gives me a little hope the Voyace can be isolated.

Hitch, if you find the time during the week to load this onto your Voyage, I'd be both grateful and interested to see, how it responds to the @media queries. I'll probably have to either get my own Voyage, or convince the Powers that Be that I won't live long enough for this issue to be ever fixed.

Klaus

PS: I add the @mediaqueries used in the demo book here because the way I create my books the CSS is packed so tightly you need a screen that's one line tall and gazillions of columns wide.

p.mobi,p.kf8,p.notmobi,p.notkf8,p.vdevdim1,p.vdevdim2,p.vdim1,p.vdim2,p.fireall,p.einkall,p.pwhitesall,p.voyoasis1,p.voyoasis2 {display:none;}
@media amzn-mobi {
	p.mobi{display:block;}
}
@media amzn-kf8 {
	p.kf8{display:block;}
}
@media not amzn-mobi {
	p.notmobi{display:block;}
}
@media not amzn-kf8 {
	p.notkf8{display:block;}
}
@media  amzn-kf8 and (device-height: 1448px) and (device-width: 1072px),
	amzn-kf8 and (device-height: 1072px) and (device-width: 1448px) {
	p.vdevdim1{display:block;}
}
@media  amzn-kf8 and (device-height: 1440px) and (device-width: 1080px),
	amzn-kf8 and (device-height: 1080px) and (device-width: 1440px) {
	p.vdevdim2{display:block;}
}
@media  amzn-kf8 and (height: 1448px) and (width: 1072px),
	amzn-kf8 and (height: 1072px) and (width: 1448px) {
	p.vdim1{display:block;}
}
@media  amzn-kf8 and (height: 1440px) and (width: 1080px),
	amzn-kf8 and (height: 1080px) and (width: 1440px) {
	p.vdim2{display:block;}
}
/* see https://gist.github.com/dvschultz/8324974 */
@media screen and (device-aspect-ratio:1/1) {
	/* "anything in here will work on Fires. Seriously." see github url above */
	p.fireall{display:block;}
}
@media not all and (device-aspect-ratio:1/1) {
	/* "anything in here will work on e-inks" see github url above */
	p.einkall{display:block;}
}
@media	amzn-kf8 and (device-height: 1024px) and (device-width: 758px),
	amzn-kf8 and (device-height: 758px) and (device-width: 1024px),
	amzn-kf8 and (device-height: 800px) and (device-width: 600px), 
	amzn-kf8 and (device-height: 600px) and (device-width: 800px),
	amzn-kf8 and (device-height: 1448px) and (device-width: 1072px),
	amzn-kf8 and (device-height: 1072px) and (device-width: 1448px) {
	p.pwhitesall{display:block;}
}
@media	not all and (device-aspect-ratio:1/1) and (device-height: 1448px) and (device-width: 1072px),
	not all and (device-aspect-ratio:1/1) and (device-height: 1072px) and (device-width: 1448px) {
	p.voyoasis1{display:block;}
}
@media	not all and (device-aspect-ratio:1/1) and (device-height: 1440px) and (device-width: 1080px),
	not all and (device-aspect-ratio:1/1) and (device-height: 1080px) and (device-width: 1440px) {
	p.voyoasis2{display:block;}
}

[Doitsu]

I've tested azw3 and kfx versions of your book on my Kindle Paperwhite 2. For results, see the attached screenshots.

BTW, the KFX code doesn't like the following selectors:

box-sizing: border-box;
box-sizing: inherit;

I had to remove them to create the kfx file.

Unless, they're essential for your styles, you might want to remove them.

[RbnJrg]

Originally Posted by kso

Tables, as suggested by Hitch, or display:table (row, cell) as suggested by RbnJrg, do not work in my case. As soon as one of the images in a row is set to be a slightly more than 50% of the column width, bang, up it blows to 100% width, and the other one is squashed like a bean stalk and, listen to this, shoved into the margin beside the table (if you ever need to position something in the margin, you now know how it's done).

If the added width of your two images is less than 100% then you shouldn't have such issues. You need to employ a table of two columns; what are you using now? If you gives a image a width of 55% and the other a width of 43% (and the table has a width of 100%), and you put the images in different columns and still you have troubles, there must be something wrong with your code. Can you post here two of your probematic images?