New plugin for KF7(mobi) image compatibility ?

[slowsmile]

@Hitch...I'm not really sure why you have to do such complex testing.

As far as I can see, two questions need to be answered:

* Does an epub image, formatted as KF8(as a percentage), display incorrectly on the old Kindle Previewer and on the new Kindle Previewer 3 eInk emulations?

* Does my plugin work on actual KF7 and KF8 devices?

First thing to prove is whether or not my plugin works or not and gives correct displays on actual KF7 and KF8 devices. If my plugin does work then this will make the next test much easier to prove.

Test on KP and KP3 only for proper KP7 emulation using both pixel values and % values:

* Run the test epub through the new plugin.

* Then remove the media query files from the bottom of the appropriate stylesheet.

* Remove the class declarations in from within the <img> tags on both the KF7 and KF8 image lines in the epub. Both images should be displayed on KF8. But only one image should be displayed on KF7 emulations(pixel image only) on KP and KP3.

* Test all outcomes only on KP and KP3 only.

If you want to vary the size of the % value, you can either do it manually in the html or you can change the base width value(fixed screen width value used in the % calculation). The base width value is inversely proportional to the % value. So if you increase the base width value to 1000 then the displayed image will be smaller. If you decrease the base width value then the displayed the image size will increase.

This test will prove whether the both KP eInk emulations are correct or not for images formatted with % values.

[st_albert]

Originally Posted by Tex2002ans

Under each Width, there are 3 images:

• orig
• kf7px##
  
  • This is resized height/width with exact px
    
    • Example: 80% -> 1000x200 = 800px x 160px
      
• kf8pc##
  
  • Just the width is resized to a given percent.

I'm confused (as usual). I thought that when you specify say width="80%" it refers to the width of the display, not the width of the image. But it looks like when you calculate the pixel dimensions, you are using a percentage of the image dimensions. Thus if the screen is 600 px wide, shouldn't you want width="480" for 80%?



Albert

[slowsmile]

What the heck. If anyone else wants to test my new plugin, then here it is.

I think it will perhaps be more useful if we get as many people involved in testing this plugin as possible.

All I really need to know is whether an epub (after running my Sigil plugin and converting to Kindle using kindlegen) works properly or not on actual KF7 devices and KF8 devices. Any help with this would be greatly appreciated.

I've also added a README.html file to the plugin zip directory which will help to explain what the plugin does.

I'll release this plugin in the proper way when I'm satisfied that the plugin works correctly on both KF7 and KF8 devices. See below for the plugin download.

[st_albert]

Originally Posted by slowsmile

* Remove the class declarations in from within the <img> tags on both the KF7 and KF8 image lines in the epub. Both images should be displayed on KF8. But only one image should be displayed on KF7 emulations(pixel images only) on KP and KP3.

If I understand correctly what you are doing here, I predict that both images will be displayed, but only the pixel-coded one will display as intended (unless by chance, the %-coded one happens to have just the right native image size, or something.)

Albert

[slowsmile]

@st_albert...Hitch has said that KF7 devices cannot or should not display images where the height and width values are in percentages(KF7 devices can only display images in pixels). I absolutely believe Hitch is right here -- no arguments from me about this.

What I am currently disputing is that the old Kindle Previewer and the newer Kindle Previewer 3 apps will display images formatted as percentage values for all their eInk or KF7 emulations. This is all wrong -- their eInk emulations should not display images as percentage values. Only images where the height/width are defined in pixels should be displayed on their KF7 emulations.

[st_albert]

Originally Posted by slowsmile

@st_albert...Hitch has said that KF7 devices cannot or should not display images where the height and width values are in percentages(KF7 devices can only display images in pixels). I absolutely believe Hitch is right here -- no arguments from me about this.

What I am currently disputing is that the old Kindle Previewer and the newer Kindle Previewer 3 apps will display images formatted as percentage values for all their eInk or KF7 emulations. This is all wrong -- their eInk emulations should not display images as percentage values. Only images where the height/width are defined in pixels should be displayed on their KF7 emulations.

I think we're talking about two different things. I should have been clearer. Let me go through what I think is happening with image tags specifying a width in percent. This is an example from a test I actually ran on that old epub->mobi I have mentioned before. I took the old epub and ran it through a modern kindlegen to produce a dual-format mobi, which I then split into its KF7 and KF8 components, and examined the html code in the kf7 part.

So in the source epub, image tags were coded like this:

<p class="center"><img alt="images/image002.jpg" src="../Images/image002.jpg" style="width:77%" /></p>

(this was taken from the source-code section of the dual-format mobi, so it's fair dinkum.

That particular line ended up in the KF7 mobi file as:

<p align="center"><img alt="images/image002.jpg" src="Images/image00015.jpeg"/></p>

Note that the width directive had been stripped out, but the image tag is still there. It will display with dimensions of the original image or full-screen, which ever is smaller. I think. But, it will display, I'm sure. Remember, I'm ONLY testing this in the previewer v.2.8 emulation of a DX. If that emulation is fubar, as Hitch suspects, then all bets are off for real-world devices. Which is one of the things we're trying to determine here, right?

Additionally, note that in the KF7 code, the image itself has been renamed, though the alt= information is the same. I have no idea what that's all about; the original image from the source code seems identical to the image that ships with the mobi file. It hasn't been resized or anything.

I grabbed your plugin, but I dare not start playing with it tonight, as my brain is about to reach its melting point

OK, hope I've clarified what I meant by my prediction that both images will be displayed, but only the pixel-value width specification will be honored. The other one won't have any width specification at all. Vide infra.

And thanks for all your-all's (meaning all the contributors to this thread -- it's Southern-speak) efforts and discussion! I'm learning much.

Albert

[slowsmile]

st_albert...Yes that is a strange result that you got.

But how did you split your original Kindlegen mobi into KF7 and KF8 versions?

If you used Calibre to do it, then that will give you the result that you got. I also ran the test using Calibre with the same result as you. And it was very evident to me that Calibre deliberately strips out all media queries from the stylesheet. It also strips out all classes and height/width definitions from the <img> tags. The gist is that you cannot rely on Calibre to give you a correct view of your mobi or AZW file.

A much better way of doing the same thing would perhaps be to run the plugin then convert your epub to mobi using Kindlegen, then download DiapDealer's KindleImport plugin(which uses KindleUnpack) and run your mobi through that in Sigil to give you an epub version. That's what I did and everything was there - including media queries and all the proper image formatting(from running the plugin)

[Hitch]

Originally Posted by st_albert

I think we're talking about two different things. I should have been clearer. Let me go through what I think is happening with image tags specifying a width in percent. This is an example from a test I actually ran on that old epub->mobi I have mentioned before. I took the old epub and ran it through a modern kindlegen to produce a dual-format mobi, which I then split into its KF7 and KF8 components, and examined the html code in the kf7 part.
<snipppage>

That particular line ended up in the KF7 mobi file as:

<p align="center"><img alt="images/image002.jpg" src="Images/image00015.jpeg"/></p>

<snippage>

Additionally, note that in the KF7 code, the image itself has been renamed, though the alt= information is the same. I have no idea what that's all about; the original image from the source code seems identical to the image that ships with the mobi file. It hasn't been resized or anything.

I grabbed your plugin, but I dare not start playing with it tonight, as my brain is about to reach its melting point
<snippage>

And thanks for all your-all's (meaning all the contributors to this thread -- it's Southern-speak) efforts and discussion! I'm learning much.

Albert

Albert:

I think--and this is NOT something I've spent a lot of time on, so this is about as good as rampant speculation--that's (renaming the images) related to the HD/non-HD images thing. That's what I think.

And yes: KF7 images will, of course, display; my thing is, they just will "do their own thing," based on their original size, the size of the device and the firmware, rather than obeying any KF8-style commands.

I'm kinda fragged, tonight, William, so I hope you'll forgive me if I don't get that next set of tests done. I push a lot, from Mon-Weds night (for example, been at work, since Mon. a.m., for 39 hours, as of right now), so...I'm kinda lamebrained at the moment.

Hitch

[st_albert]

I'm a linux guy, where possible. I did use the stand-alone kindleunpack.py to split the dual-format mobi.

Just as a teaser, I ran a test epub, along the lines of what Hitch suggested, but very, very, bare bones, through kindlegen (command line version 2.9) and got somewhat more complicated results. I need to dig deeper into these results, but note that this was the first time I passed an epub through kindlegen that contained any pixel-dimension coding at all. The results are confusing. Stay tuned.

For now, gn8 and sleep well.

Albert

[slowsmile]

@Hitch...Please don't get all stressed about these problems on my account. Take your time and have a restful weekend, if that's possible. I know how hard you work and can only guess at how stressful it must be for you. Perhaps gently sipping a whisky later would help...maybe one or two or three or...works wonders for me...

[st_albert]

Originally Posted by Hitch

Albert:

I think--and this is NOT something I've spent a lot of time on, so this is about as good as rampant speculation--that's (renaming the images) related to the HD/non-HD images thing. That's what I think.

I agree. When kindleunpack is done there is a directory called HDImages. It is usually empty in my cases.
.

Originally Posted by Hitch

And yes: KF7 images will, of course, display; my thing is, they just will "do their own thing," based on their original size, the size of the device and the firmware, rather than obeying any KF8-style commands.

Exactly. That was what I was trying to say.

More on the morrow, when I've had a chance to sleep on it.

Albert

[Hitch]

Originally Posted by slowsmile

@Hitch...Please don't get all stressed about these problems on my account. Take your time and have a restful weekend, if that's possible. I know how hard you work and can only guess at how stressful it must be for you. Perhaps gently sipping a whisky later would help...maybe one or two or three or...works wonders for me...

LOL, well, thanks, William, but I have 3 days in this workweek left--we're open through Saturday evening, so...the "weekend" for me is a long way off. And as much as I wish I could have a sip of the Demon Rum, I'm afraid I had to give that up a long time ago, nearly 30 years back. Let's just say, shades of Bill Bixby, "you wouldn't like me when I've been drinking." :-)

Hitch

[slowsmile]

@Hitch...I've been thinking about your Voyager problem -- where any images that are defined over 50% immediately blow up to 100% for no apparent reason.

And you're probably not going to like my possible solution to the above problem. My suggestion is that you could use the !important modifier to override any funnies that are beiing caused by the Voyager's firmware. In other words the Kindle overrides on Voyager will no longer be able to change your values.

You could program your Voyager image like this:

<p class="image-style"><img alt="" src="../Images/image001.jpg" class="imgsize1"/></p>

Then define the class in the CSS like this:

.imgsize1  {
width: 60% !important;
height: auto !important;
}

The above declaration will be a higher priority than any Kindle override and should technically work.

I know you don't like the above solution, but -- hey -- if you have no other solution then I would use it. Worth a try FWIW.

[slowsmile]

LOL..."Shades of Bill Bixby..."...Well Hitch I guess I'm lucky because I don't turn green but if I have one over the top all that happens is that I just melt into my old rocking chair with a silly grin on my face. My Dad also taught me a thing or two - I follow his advice now which is: Never drink alone and only drink after 6:00pm in the evening. Been following that advice for 37 years. All I can say is that it works for me...

[Hitch]

Originally Posted by slowsmile

@Hitch...I've been thinking about your Voyager problem -- where any images that are defined over 50% immediately blow up to 100% for no apparent reason.

<snippage on using the !important modifier>

I know you don't like the above solution, but -- hey -- if you have no other solution then I would use it. Worth a try FWIW.

Hi:

Well, the bigger problem is, even Amazon admits it's a bug. :-) And, for those of you that didn't read this or weren't around, etc., for this discussion, here, a while back, the problem is, it wasn't just a bug with the Emulator--it was in the actual device software, too.

Strewth, I haven't checked recently, to see if that's been resolved. It may well have been. The only reason I brought it up is the DX thing. I wonder, now, if the Voyage, et al issue had its roots in a heretofore undiscussed/unnoticed glitch in the DX. Ya know?

I think--but can't quite recall--that we tried using that, then, when we discovered it and reported it to Amazon. But I'd be lying if I claimed to recall precisely; it's been...hell, 3 years or maybe even more?

LOL..."Shades of Bill Bixby..."...Well Hitch I guess I'm lucky because I don't turn green but if I have one over the top all that happens is that I just melt into my old rocking chair with a silly grin on my face. My Dad also taught me a thing or two - I follow his advice now which is: Never drink alone and only drink after 6:00pm in the evening. Been following that advice for 37 years. All I can say is that it works for me...

Yeah, well, suffice to say, that wouldn't work for some of us. :-) But thanks for the thought.

Hitch