New plugin for KF7(mobi) image compatibility ?

[Hitch]

Originally Posted by slowsmile

@Hitch...I've just resent you the test epub and the mobi version as well.

I am also completely clueless as to why, whenever I test these epubs/mobis on KP(v2.94) and KP3(v3.13), they show the larger image(as a %) on all eInk emulations whereas other people are getting different results.

The important thing for me is whether the new plugin works or not. For that I need someone to confirm whether the plugin works(ie displays images in only pixels) on an actual K2 device or not.

Well, I understand that the plugin is important, but, William, we need to sort the KF7 image thing for you, too.

Hitch

[Hitch]

Originally Posted by slowsmile

@Hitch...I've just resent you the test epub and the mobi version as well.

I am also completely clueless as to why, whenever I test these epubs/mobis on KP(v2.94) and KP3(v3.13), they show the larger image(as a %) on all eInk emulations whereas other people are getting different results.

The important thing for me is whether the new plugin works or not. For that I need someone to confirm whether the plugin works(ie displays images in only pixels) on an actual K2 device or not.

William: You're building this with KP or KG, right? Are you dropping the ePUB(s) on KP 2.94? Or..?

Hitch

[slowsmile]

@Hitch...I've only used the older KP and KP3 to test the plugin. And I have also used KG with the same result. And, yes, for KP I am dropping the test files into the app.

I agree with you that this KP and KP3 thing is important but I regard that issue as an entirely separate issue that has nothing whatsoever to do with the K2 device testing for my plugin. After all, this thread is all about whether its worth releasing the plugin and so far already a week has passed since I sent you the plugin and I still don't have a result -- ie no result as to whether my plugin works properly when tested on an actual K2 device. Just wondering when that is going to happen.

[slowsmile]

If anyone else would like to test my plugin on their old eInk device(KF7 device) then you can download my plugin from here:

https://www.mobileread.com/forums/sh...9&postcount=33

There is a README file in the zipfile plugin directory that explains what the plugin does.

[Hitch]

Originally Posted by slowsmile

@Hitch...I've only used the older KP and KP3 to test the plugin. And I have also used KG with the same result. And, yes, for KP I am dropping the test files into the app.

I agree with you that this KP and KP3 thing is important but I regard that issue as an entirely separate issue that has nothing whatsoever to do with the K2 device testing for my plugin. After all, this thread is all about whether its worth releasing the plugin and so far already a week has passed since I sent you the plugin and I still don't have a result -- ie no result as to whether my plugin works properly when tested on an actual K2 device. Just wondering when that is going to happen.

I told you that the plugin seems to work great. No, I haven't actually taken one I used the plugin on, and put it on the real K2, but that's because in my testing, William, so far, I'm seeing results that I expect. What I'm not seeing is what you are apparently seeing--this thing with images looking, on a KF7 emulator, as though they are being sized using the KF8 numbers.

Since what I'm seeing, is what I expect to see, I hadn't seen any reason to "double-test" it on the K2, but I shall do that tonight if it will ease your mind. After all, we've seen your plugin results, which is good code. It's not going to look different on the real device than it does on the emulator, at least, not at my end. The px settings are correct. To me, that says everything.

But, as I said: to ease your mind, I shall take the same test ePUB you sent me, the Paco one, and put it on my K2, take some screenshots and show all you guys the Kf7 emulation and the real K2 together.

Hitch

[Hitch]

OK, gang:

As William seems very worried about the plugin, on a real device, I've tested it. The code seems to work fine--it outputs perfectly good KF7/KF8 coding. To be honest, I confess that I don't understand why you think, William, that the book on a real device would perform worse than on the emulator--I thought that the idea was that the emulator was performing worse than the real device--but I'm here to tell you that it's performing fine, on both, and the KF7 images look exactly as expected.

Here are two screenshots, from the test file (ePUB) that you sent me, which I then built into a MOBI, both on KP 2.94 and KP 3.13; the mobi results were identical, so no point in double-posting those. The KP 2.94 is named "Screenshot 2681.gif" and the "Test_Williams...yadda.jpg" is the emulator. The Fire device image is also the emulator, but I tested this on my matching Fire device, as well, and it's accurate.

I included the one on the "Fire" emulator, for comparative purposes. As you can see, they are WILDLY different, so the DX emulator on the KP 2.94 is NOT, remotely, showing images at the KF8 coding.

The DX emulator and the real K2 show the image exactly the same.

I used, built and tested Tex's test ePUB, and your test ePUB, Wiliam, both, and I have not seen any evidence, whatsoever, that the KF7 emulator is buggy, vis-a-vis image display for the correct coding.

The plugin seems to work a treat.

Hope this helps. If you are still seeing images, William, that look to you as though they are displaying KF8 size, when they should be showing KF8, you should send me THAT MOBI, or post it here for the gang, so that I/we can look at it, and see what you're seeing. Maybe we can figure out what's what if we both/all look at it.

Hitch

[slowsmile]

Hitch...My thanks for confirming that the plugin works on your K2 device.

Hitch said..

"As William seems very worried about the plugin, on a real device, I've tested it. The code seems to work fine--it outputs perfectly good KF7/KF8 coding. To be honest, I confess that I don't understand why you think, William, that the book on a real device would perform worse than on the emulator--I thought that the idea was that the emulator was performing worse than the real device--but I'm here to tell you that it's performing fine, on both, and the KF7 images look exactly as expected."

Well Hitch the reason might be because I think that we both might have missed something. We have both perhaps assumed that the other was formatting their percentage image line in the same format. But the truth of what I suspect is that you may have been formatting all your test epubs for KP and KP3 in standard image percentage formatting(just using the height/width attributes in an image tag) whereas I have been formatting all my height/width percentage values in the image tag as an inline style viz. in other words -- concerning the the strange and conflicting KP and KP3 problems -- we might have unknowingly been formatting the percentage values in different ways which might well have caused different results or outcomes for each of us on KP and KP3 eInk emulations.

If what I'm saying is true you wont even need to use my plugin to prove this. And I think we are both agreed that if you format an ebook image in standard formatting with percentage values then it will not display on a KF7 device.

I've even prepared a simple epub test file for you as an attachment below to make it easier for you to see this for yourself. This epub contains my image styling (using inline styling with % values in the image tag) just for one image. All you or anyone else has to do is run this epub on KP and KP3 eInk emulations and you will see the image above the title displayed as plain as day(which is what I am seeing). This proves to me that if you format your image using this inline style method then that image will be displayed on all KF7 emulations. Please also note that this styling also works for all KF8 emulations as well.

And if you or anyone else confirms my findings then that also would seem to further indicate that media queries and dual formatting are completely unnecessary for KF7 and KF8 images. All you really have to do is format a single image line using % values for height and width inside an inline style within an image tag and the image will appropriately display on all KP and KP3 eInk emulations and will also display correctly on all KF8 emulations as well.

[roger64]

Hi

I found in the CSS stylesheet some "long hand" values like this one where some spaces seem to be missing.

margin: 0em0em0em0em;

The cover image uses an inline value

style="height: 100%;"

Maybe I am wrong, but it would maybe seem safer to add a width percentage because this percentage alone can work only if the image is contained within its own page and could cause problems in continuous scroll mode. I remarked that the W3S did not provide example of height:100% used alone.

As I do not own old Kindle devices, I can't test your display but your comment about the usefulness of the inline style is quite interesting and I am curious to know the result.

[slowsmile]

roger64...I think you may have that the wrong way round. Shorthand margin values are like this:

margin: 0;
margin: 0 1em;
margin: 0 1em 1em;
margin: 1em 0em 0em 1em;

The long form or explicit form is like this:

margin-top: 1em;
margin-bottom: 1em;
margin-left: 0.5em;
margin-right: 0em;

Also the margin value really has nothing whatsoever to do with inline height/width values in an image tag.

You might also like to investigate my new plugin -- ConvertAbs2RelCSSValues -- which converts all cm, mm, inch, pt and pica values to em values in the CSS. It also converts all shorthand forms of 'margin' and 'padding' to the long form. I think reading the release notes for this plugin might also help you understand more about this.

[roger64]

Sorry for not being precise. I read some shorthand values in the css stylesheet, not related to img tags but faulty anyway like the one I posted.

[st_albert]

@slowsmile, @hitch:

I downloaded the Test2.epub, but I wanted to see if the width: xx% inline styling was actually being correctly interpreted in KF7 emulations. So I modified the title page by copying the img tag , and changing the width to 20%. So now there are two images, one at 50% and one at 20%.

I converted it to dual-format mobi via kindlegen from the command line. In KP version 2.85 (N.B, dated 2012) both images were displayed as the same size in DX and K3 emulations, but did display as intended in paperwhite and fire.

I attach a zip file with both the epub and mobi for your perusal.

Also, when I tried the plugin on the modified epub, it made both images width: 16% for the kf8 styling. Is this supposed to happen? (plugin version 0.1.3)?

Albert

[Hitch]

Originally Posted by slowsmile

Hitch...My thanks for confirming that the plugin works on your K2 device.
<SNIP>

Well Hitch the reason might be because I think that we both might have missed something. We have both perhaps assumed that the other was formatting their percentage image line in the same format. But the truth of what I suspect is that you may have been formatting all your test epubs for KP and KP3 in standard image percentage formatting(just using the height/width attributes in an image tag) whereas I have been formatting all my height/width percentage values in the image tag as an inline style viz. in other words -- concerning the the strange and conflicting KP and KP3 problems -- we might have unknowingly been formatting the percentage values in different ways which might well have caused different results or outcomes for each of us on KP and KP3 eInk emulations.

If what I'm saying is true you wont even need to use my plugin to prove this. And I think we are both agreed that if you format an ebook image in standard formatting with percentage values then it will not display on a KF7 device.

I've even prepared a simple epub test file for you as an attachment below to make it easier for you to see this for yourself. This epub contains my image styling (using inline styling with % values in the image tag) just for one image. All you or anyone else has to do is run this epub on KP and KP3 eInk emulations and you will see the image above the title displayed as plain as day(which is what I am seeing). This proves to me that if you format your image using this inline style method then that image will be displayed on all KF7 emulations. Please also note that this styling also works for all KF8 emulations as well.

And if you or anyone else confirms my findings then that also would seem to further indicate that media queries and dual formatting are completely unnecessary for KF7 and KF8 images. All you really have to do is format a single image line using % values for height and width inside an inline style within an image tag and the image will appropriately display on all KP and KP3 eInk emulations and will also display correctly on all KF8 emulations as well.

William:

FWIW, I didn't touch your previous "Paco" (ePUB1, let's call it) ePUB. I took the ePUB1 you sent me, dropped it on KP, and that's what I looked at. Now, maybe I've skimmed your post too quickly, but I didn't "format" bupkus. Literally. I took whatever you had done, in the "Paco" ePUB you sent me, and dropped/viewed it. So, the coding was yours. Maybe I've misunderstood what you mean, in your post, so, moving along:

Now, about inline %: we've tried this coding, using inline %, over the years. And discarded it. I'm not sure I understand why you think it works.

You have it coded as width:50%, which means, unless I left my CSS brain at the station this morning, 50% of the width of the containing block. Do we agree on that?

The coding, for everybody else who didn't have time to view the ePUB:

  <p class="scrivener5"><img alt="" src="../Images/eagle.jpg" style="width: 50%;height: auto;"/></p>

in which the p class "scrivener 5" is defined as:

.scrivener5  {
margin-left: 0em;
text-align: center;
margin-bottom: 0em;
margin-top: 0.5em;
margin-right: 0em;
text-indent: 0em;
}

Because if we agree that the CSS means 50% of the containing block, then I don't understand why you think that this coding is working. Please see attached images, for screenshots from the emulator (which I think I demonstrated, last night, is working--do we all agree on that?). I've attached:

• Screenshot from the KP2.94, FireHD;
• Screenshot from the KP2.94 Fire HDX;
• Screenshot from the KP2.94 Fire HDX 8.9";
• Screenshot from the KP 2.94 Voyage; and,
• Screenshot from the KP2.94 DX emulation.

Your coding says, 50% of the width of the screen, which is the containing block because the Scrivener 5 class doesn't constrain the size; you use it to center the image, only (and provide top margin spacing). Right?

Well, Wiliam, that Eagle damn sure ain't half the screen, in the DX. The DX is 824pixels wide, so this SHOULD be ~400px in width--and it's obviously not, given the original image is 90px wide. Is this what you're seeing, at your end? My best estimation is that the eagle is displaying slightly over its original size. Perhaps, 125-150% of its actual size.

The KF8s all seem to be about right. Do we all agree on that?

What am I missing? I mean that; we all know that I don't code daily, so I forget stuff. Freely admit it. What's working, in the DX screenshot? I mean, as it happens, the size of the Eagle image, on that screen, for that moment, works, even though it's not obeying the coding, but that's...coincidence. If it were, say, twice the size, it wouldn't.

So: what do you think is happening here? To me, this isn't working. To me, it's displaying the image at just a bit over full-size. About 125-150pixels. Not half the size of the image, nor half the size of the screen. Hell, I don't know where it derived the size, unless we assume that like all images on KF7, the DX simply blew it up some percentage, attempting to make it fill the screen, as is KF7's wont.

Anyone else have thoughts on this? I mean...if I'm not understanding what I'm seeing, I'm happy to hear them.

Spoiler:

(Sorry, all, if this post rambles/repeats itself a bit. I was looking at these, writing, thinking, yadda, while writing. Plus I have a screamer of a headache today.)

Hitch

[st_albert]

Originally Posted by Hitch

...

Because if we agree that the CSS means 50% of the containing block, then I don't understand why you think that this coding is working. Please see attached images, for screenshots from the emulator (which I think I demonstrated, last night, is working--do we all agree on that?). I've attached:

• Screenshot from the KP2.94, FireHD;
• Screenshot from the KP2.94 Fire HDX;
• Screenshot from the KP2.94 Fire HDX 8.9";
• Screenshot from the KP 2.94 Voyage; and,
• Screenshot from the KP2.94 DX emulation.

Your coding says, 50% of the width of the screen, which is the containing block because the Scrivener 5 class doesn't constrain the size; you use it to center the image, only (and provide top margin spacing). Right?

Well, Wiliam, that Eagle damn sure ain't half the screen, in the DX. The DX is 824pixels wide, so this SHOULD be ~400px in width--and it's obviously not, given the original image is 90px wide. Is this what you're seeing, at your end? My best estimation is that the eagle is displaying slightly over its original size. Perhaps, 125-150% of its actual size.

The KF8s all seem to be about right. Do we all agree on that?

What am I missing? I mean that; we all know that I don't code daily, so I forget stuff. Freely admit it. What's working, in the DX screenshot? I mean, as it happens, the size of the Eagle image, on that screen, for that moment, works, even though it's not obeying the coding, but that's...coincidence. If it were, say, twice the size, it wouldn't.

So: what do you think is happening here? To me, this isn't working. To me, it's displaying the image at just a bit over full-size. About 125-150pixels. Not half the size of the image, nor half the size of the screen. Hell, I don't know where it derived the size, unless we assume that like all images on KF7, the DX simply blew it up some percentage, attempting to make it fill the screen, as is KF7's wont.

Anyone else have thoughts on this? I mean...if I'm not understanding what I'm seeing, I'm happy to hear them.

Hitch

I concur with your observations. My take is that the KF7 version of the mobi file simply ignores the width specification (probably doesn't even include them in the kf7's html.). I haven't had time yet to dissect the mobi file to check on its coding, though. (*)

See my post #71 above. I duplicated the image code on the title page , then changed the width of the second image to 20%. On KF7 emulators, both images were the same size, and seemingly < 50% of screen width. On KF8, they were different sizes, but I'm still not sure that the larger was all of 50%. Maybe I need to put a border on the actual image to see what its bounds are.

Albert

* Edited to add:
When I looked inside the dual mobi, split apart with Kindleunpack, here's what I found regarding how the images were coded.

First, code in the modified test2 starting epub (on the title page) was:

  
<p class="scrivener5"><img alt="" src="../Images/eagle.jpg" style="width: 50%;height: auto;"/></p>

<!-- same image again, but width:20%  -->

  <p class="scrivener5"><img alt="" src="../Images/eagle.jpg" style="width: 20%;height: auto;"/></p>

whereas, kindlegen did the following:

coding in the book.html file from KF7 book (linefeeds added)

<mbp:pagebreak/><a id="filepos910" />
<p height="1em" width="0em" align="center">
<font face="Times New Roman">
<img alt="" src="Images/image00018.jpeg"/></font>
</p> 
<p height="1em" width="0em" align="center">
<font face="Times New Roman">
<img alt="" src="Images/image00018.jpeg"/>
</font>
</p>

Note that both are now identical and have no width/height specs at all.

coding in corresponding kf8 file:

  <p class="scrivener5"><img alt="" src="../Images/image00018.jpeg" style="width: 50%;height: auto;"/></p>

  <p class="scrivener5"><img alt="" src="../Images/image00018.jpeg" style="width: 20%;height: auto;"/></p>

Thus it is clear that coding width/height in % in the source epub has no impact on the KF7 mobi file. I.e. it is completely ignored.

-- A.

[Hitch]

Originally Posted by st_albert

I concur with your observations. My take is that the KF7 version of the mobi file simply ignores the width specification (probably doesn't even include them in the kf7's html.). I haven't had time yet to dissect the mobi file to check on its coding, though.

See my post #71 above. I duplicated the image code on the title page , then changed the width of the second image to 20%. On KF7 emulators, both images were the same size, and seemingly < 50% of screen width. On KF8, they were different sizes, but I'm still not sure that the larger was all of 50%. Maybe I need to put a border on the actual image to see what its bounds are.

Albert

OK, good. I was starting to wonder if I was losing my mind, or if I'd missed something, to be honest. (The other day, when using Tex's ePUB, I actually got a bit corn-fused for a moment, thinking that images should have been 50% of the screenwidth--when the coding was, 50% of the size of the original image. That had me going for a few minutes. So, I never rule out the possibility/likelihood that I'm brain-farting!)

I looked at your test ePUB/MOBI. I think that the eagle image is deceptive--it's wider than you think, due to the slanting nature of the wings and extended talons, and the fact that it has some pixels of whitespace to the left of the extended talons. I'll bet you that the eagle is, absolutely, dead spot on 50%. If you look at the portion of the image to the LEFT of the talons--which is a good bit of length, you can see it's deceptive.

(n.b.: I measured the image. The whitespace to the left of the talons is 16pixels. The image itself is only 90px wide. That means that 17.8% of the image's width is the whitespace to the LEFT of the talons.)

So, I'm betting that's 50%, Albert. :-)

ETA: You're a step ahead of me, Albert--I was just going to unpack that mobi and do what you did. We're in agreement on how the coding is being treated. Nice job!

Hitch

[slowsmile]

Hitch and st_albert...I'll try and clarify things.

First thing to understand is that the KP and KP3 weirdness that I'm reporting has nothing whatsoever to do with the new plugin. The problem also has nothing to do with image sizing etc.

Everyone has been saying that KF7 devices cannot display images whose height and width dimensions are in percentage values. After all, if you ask yourself the question, "Why do we need to use dual formatting and media queries for Kindle uploads..." the answer to that question is because KF7 devices cannot display image height/width using percentages values(whereas KF8 devices can). Right?

Now run this very simple test. Open the test epub that I sent Hitch(see my last post for the downloaad) on KP and KP3. Then just answer this simple question: Do you see an image on the KP and KP3 eInk displays ? If you do see an image in the eInk displays then that's the oddity or problem. Read on to find out why this is an oddity.

The test epub just contains one image coded thus:

<p class="scrivener5"><img alt="" src="../Images/eagle.jpg" style="width: 50%;height: auto;"/></p>

Please also note in the above code that I'm using inline styling with percentage values in the test epub. It also appears that everyone is seeing this image too on their KP and KP3 eInk displays too. Right?

Here's the oddity explained: Everyone has been saying that image dimensions defined in percentages within an image tag cannot be displayed on older KF7 devices. But when Hitch and I look at the KF7 displays for the test epub we both see the image(formatted with % dimensions) plain as day on our eInk emulations. Well, according to what everyone's been saying -- you should see no image if your image is using percentage values like this on KF7 devices. But the test epub IS displaying an image formatted as an inline style using percentage image values on KP and KP3 eInk displays and that's not supposed to happen. Right?

So all you have to do to confirm my findings is just open my test epub in KP and KP3 and then just report back here if you see a centered image or not in their eInk displays. And please don't complicate things by dragging in image sizing, positions etc in your observations -- the latter is completely irrelevant to this test. This test is only meant to prove or disprove whether using inline styling(with % dimensions) for ebook images will display and show ebook images on KF7 devices.

And here's the most important thing. If you confirm what I have said above to be right(just confirm if the centered image is there or not in the eInk displays-- that's all I care about!!), then there seems to be absolutely no need to use media queries with dual formatting to ensure proper image display on both KF7s and KF8s. All you have to do is just use a single image line that has been styled using inline styling with % values in your image tag and you image(s) will be appropriately displayed on both KF7 and KF8 devices without a problem.

And don't worry Hitch, I'm not going to change my plugin code because of the above discovery. But as far as I'm concerned, just bear in mind that there is not just one way to format your epub for KF7 and KF8 eInk displays for images. There is also a much easier second way of doing this as I have a already described in the paragraph above.

Hitch...It might also be interesting to know if the image in the test epub also displays properly on your K2 device or not after conversion to Kindle mobi.

Does everyone fully understand the problem or oddity that I'm reporting now? I really hope so...