New plugin for KF7(mobi) image compatibility ?

[st_albert]

Originally Posted by slowsmile

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

...

Here's the oddity: Everyone has said that images 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 this epub we both see the image(formatted with % dimensions) plain as day. Well, according to what everyone's been saying -- you should see no image if you code your image using percentages on KF7 devices. Right?

Does everyone understand the problem or oddity that I'm reporting now?

I have never said that images coded with width/height values in % will not display on KF7 devices.

In post # 34 I said:

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

and in post #36 I tried to give more detail as to what was happening during the conversion from epub to mobi KF7 using kindlegen:

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:
Code:
<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:
Code:
<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.

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.

Additionally, in posts #71 and #73, using a modification of your Test2.epub, (post 71) I demonstrated the fact that width/height values in % are ignored in the conversion to KF7, but the image tag is still there, and is displayed albeit wrongly.

If I have still been unclear, I think it's time for me to give up.

And, granted it has nothing to do with this oddity, I did see some behavior from your plugin that I thought might be buggy. It's described in the last paragraph of post #71:

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 an 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. Right?

Now run this very simple test. Open the epub that I sent Hitch(see my last post) on KP and KP3. 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.

William--do you...are you saying that you thought that what I was saying, all this time,or what Albert is saying, is that if you code an image for KF7, using a %, that it won't display AT ALL?

I never said that. And it's not what I meant, nor what I ever meant. I simply meant what I thought I said--that using %, to cause an image to display AT A SPECIFIC SIZE, would not work. I never meant that using %, either in the CSS or inline, would somehow cause the image to not show up at all.

n.b.: I just went over the prior thread, in which there was a heated discussion about this, and we NEVER said this. We stated, repeatedly, that KF7 will ignore any CSS using %, and the resulting image would just display as if no size were set, at all. Nobody ever said that the images would simply disappear as if they didn't exist.

The test epub just contains just 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 percentages. It also appears that everyone is seeing this image too on their KP and KP3 eInk displays. Right?

Yes, of course we're seeing it.

Here's the oddity explained: Everyone has been saying that images 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. Well, according to what everyone's been saying -- you should see no image if you code your image using percentages on KF7 devices. Right?

No. This is a misunderstanding. I said, the coding CANNOT be used, because it doesn't work. The image displays at the wrong size.

All you have to do to confirm my findings is just open the 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) will display ebook images correctly on KF7 devices.

It's not, really, irrelevant. You had said, at some point in time, that we could style KF7 images using %--and we can't. The resulting display is wrong. That's why I bothered to take all those images. You'd said that you'd seen KF8 and KF7 images, displaying as if BOTH were being styled by the KF8 coding. That's why I did the screenshots.

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.

William--even ignoring the fact that there's some massive misunderstanding here--didn't you notice that the image displays at the wrong size? I mean, even if we DID mean that it would somehow be turned invisible, using the %, and even assuming arguendo that were true, the end result of your coding in the single element is that the KF7 image is the wrong size.

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 image displays. There is also a much easier second way of doing this as I have a already described in the paragraph above.

As I mentioned, we have a similar clip for Epsilon, but thanks. I thought I was helping you make a plugin for other folks.

Does everyone fully understand the problem or oddity that I'm reporting now?

Well, I understand, now, what you've misunderstood about what I, Diap, etc., all said. But...honestly, William, I don't understand how you came to that misconstruction. But anyone can have a brain fart.

Nonetheless, the plugin works. The KF7 coding--the coding done correctly, with its own line of code, using Hidden, etc., works fine. The one-line coding, which we all know has nothing to do with the plugin, trying to do both KF7 and KF8, doesn't work, because the image displays incorrectly.

Are we all on the same page now?

Hitch

[slowsmile]

OMG...Why are people still talking about my plugin and dual formatting?

In my last post I specifically said and advised in the first paragraph in my last post:

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.

So why is everybody still talking about dual formatting and sizing?

Hitch said:

"William--do you...are you saying that you thought that what I was saying, all this time,or what Albert is saying, is that if you code an image for KF7, using a %, that it won't display AT ALL?"

No Hitch -- I'm saying directly the opposite of your comment above. Have you run the test epub that I sent you in my last email? If you had done that then you would have seen it. The epub only contains one image line(its NOT dual formatted for KF7 and KF8) which has been formatted using % height/width values. If you look at that epub in KF7 emulations then you will see the image -- and that shouldn't happen(because % values should not display on KF7 devies). Got it?

Hitch said:

No. This is a misunderstanding. I said, the coding CANNOT be used, because it doesn't work. The image displays at the wrong size.

Perhaps it was a misunderstanding like you say. But my take on this is that if you format % values in the standard way(using height width as attributes in an image tag) then it will not display or it will display the wrong size -- I haven't tested this so I could be wrong. But if you're using inline styling in an image tag for % height/width then that's certainly not the same as using the standard method of declaring the height/width values in an image tag. Assuming that these two methods will give the same result is also quite a dangerous assumption. And my observations when I use the inline styling method for height/width with % dimensions are that it does display correctly as a percentage of the screen width when you use inline styling for the height/width dimensions. In the test epub I sent you(which uses inline styling with percentage dimensions) I have observed that the image displays at 50% of screen size -- which is correct(Don't forget that the image of the hawk will have a larger but unseen white canvass boundary around it as well).

Hitch...All I'm really doing is passing on some observations about KF7 formatting oddities to you because I know that you like hearing about Kindle problems/oddities. I've done this deliberately because you were generous enough to fully test my new plugin for me. But I never thought that this discussion would turn into such a long discussion and create so much confusion. I hope that what I've been saying is clearer now.

To be honest with you, I really don't care that much about this oddity that I'm reporting. I'm just happy that the plugin works OK...

[st_albert]

@slowsmile
Well I don't know what to say, other than to echo H. L. Menckin

"You may be right."

So, let's get back to the plugin. Can you enlighten me about this question? (from post #71, which has more details);

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

Thanks,

Albert

who still says, pace @Hitch, KF7 delenda est.

[Hitch]

Originally Posted by slowsmile

OMG...Why are people still talking about my plugin and dual formatting?

In my last post I specifically said and advised in the first paragraph in my last post:


So why is everybody still talking about dual formatting and sizing?

Hitch said:


No Hitch -- I'm saying directly the opposite of your comment above. Have you run the test epub that I sent you in my last email? If you had done that then you would have seen it. The epub only contains one image line(its NOT dual formatted for KF7 and KF8) which has been formatted using % height/width values. If you look at that epub in KF7 emulations then you will see the image -- and that shouldn't happen(because % values should not display on KF7 devies). Got it?

Hitch said:

Perhaps it was a misunderstanding like you say. But my take on this is that if you format % values in the standard way(using height width as attributes in an image tag) then it will not display or it will display the wrong size -- I haven't tested this so I could be wrong. But if you're using inline styling in an image tag for % height/width then that's certainly not the same as using the standard method of declaring the height/width values in an image tag. Assuming that these two methods will give the same result is also quite a dangerous assumption. And my observations when I use the inline styling method for height/width with % dimensions are that it does display correctly as a percentage of the screen width when you use inline styling for the height/width dimensions. In the test epub I sent you(which uses inline styling with percentage dimensions) I have observed that the image displays at 50% of screen size -- which is correct(Don't forget that the image of the hawk will have a larger but unseen white canvass boundary around it as well).

Hitch...All I'm really doing is passing on some observations about KF7 formatting oddities to you because I know that you like hearing about Kindle problems/oddities. I've done this deliberately because you were generous enough to fully test my new plugin for me. But I never thought that this discussion would turn into such a long discussion and create so much confusion. I hope that what I've been saying is clearer now.

To be honest with you, I really don't care that much about this oddity that I'm reporting. I'm just happy that the plugin works OK...

William:

I don't think you read my post. My observations have NOTHING to do with your plugin. The image from your test2.ePUB, that you think is showing correctly, isn't. Period. It's not remotely 50% of the screen. I discussed, in pixel-detail, the white space on the left side of the image, too.

I used YOUR coding, inline. I tested YOUR ePUB. It's not displaying correctly in KF7. That's it, William. It has nothing to do with the plugin.

ETA:

Please go back, William, and read my post 72: https://www.mobileread.com/forums/sh...8&postcount=72 . The first paragraph of my response talks about the plugin--but the rest is ALL about nothing but KF7 and how the images display.

View the KF7 image, of which I've taken a screenshot, in that post. Not even you can assert that that image is remotely 400+ pixels wide, which is what it would have to be, if it were obeying the instruction, the inline instruction, that you're saying works. It doesn't. It's not an anomaly. You're seeing something incorrectly.

Hitch

[slowsmile]

st_albert...Because the plugin calculates the image size to a base fixed width size I'm afraid that a ballpark or average image size can only be expected from the calculation I used in the plugin which is shown below:

Image-width-inpixels/630 x 100

And because the base screen width is 630px -- a fixed value -- that also means there will always be variance because the widths from all readers will always vary a little from that 630 base width value.. So this plugin certainly is not perfect. But it will still save you alot of time even if you have to adjust the the individual % widths to your own liking. That's surely quicker than having to manually dual format every single image in your epub which, as Hitch has said, is a long drudge job if you have to dual format 200 images in your epub.

In the plugin there is also an option that allows you to vary the base width value. If you enter a BWV that is larger than the default all the images in your ebook will decrease in size. If you increase it all your ebook images will decrease in size. Best I could I'm afraid.

[slowsmile]

@Hitch...Well we could go round in circles like this for days.

Since it's impossible to do an accurate measurement of the KF7 displays for KP and KP3, I've been wondering how you measured the white image canvass widths. Both the old KP and the newer KP3 have no Night mode on their KF7 displays. So how did you measure the white canvass background width of the image?

And the KP3 can now display KF7 displays with it's new "Kindle E-reader" option for KF7 displays. Did you know that? There is no night mode on that KP3 either for the "Kindle E-reader" display. And its probably the case that there is no Night mode in the eInk hardware version either.

Here's how I did it and got one of my results -- and yes this is an approximate result. The eInk and Fire HDX displays on the old KP app have approximately the same screen width on KP. So, if both screen display widths are the same then both the displayed images -- on the Fire HDX and the eInk displays -- should display at the same width size. This was indeed the case when I checked. Both the image on the FireHDX(KF8) display and the eInk diplays were approximately the same when I used my Test epub image.

And I did look at the images you posted in your post(#72).

Here, for comparison, are my images from the same epub test file which are taken from the old KP displays. They also appear to be very different from your thumbnails.

.

[slowsmile]

@Hitch....And here are my images from the same test epub for the KP3 "Tablet"(KF8) and "Kindle E-reader"(KF7) displays.

[slowsmile]

@Hitch...And if you want my honest opinion, I have never really trusted the text or image displays from the older KP app. But I do trust these displays in the KP3 app. Reasons? The old KP app hasn't been updated in a donkey's age whereas the newer KP3 app has already been updated 6 or 7 times this year. So KP3 is the more reliable app because it is being properly maintained with regular updates whereas the older KP app has not been properly maintained because updates are rare.

Now over to the KP3 displays that I trust. If you click on each of my KP3 images above in turn(or download them for proper image display)-- first the Tablet-KF8-KP3.jpg and then the KindleReader-eInk-KP3.jpg -- then enlarge and compare them you will also note that the image sizes of both versions is exactly the same. And since, in this test, both screen widths and both image widths are the same size -- the screen width does not change for each test on KP3 -- then I would really expect the two image displays to be the exactly same size which was the case in my testing. Which must also ultimately prove that this styling(inline styling using % dimensions) works just fine on both KF7 and KF8 devices. If the styling wasn't functioning correctly in the KF7 version then the KF7/KF8 image displays would not be the same size. Right? But they are the same size...

It's also plain to see that you only tested the epub on the old KP app. And you obviously haven't yet tested that epub on the newer KP3 app. I've now shown you that the KF8 and KF7 displays on the KP3 app are the same size(because both screen widths and both images are exactly the same size) on my tests which was the expected result. This directly conflicts with your own test results on the old KP app(which I have never really trusted).

You could of course actually try loading the mobi version of the test epub into your old eInk device and have a look. But, unfortunately, there is no way that I can see how you could accurately measure the image width(ie by measuring the larger but invisible white canvass background) on your device accurately. Over to you.

[Hitch]

Originally Posted by slowsmile

@Hitch...And if you want my honest opinion, I have never really trusted the text or image displays from the older KP app. But I do trust these displays in the KP3 app. Reasons? The old KP app hasn't been updated in a donkey's age whereas the newer KP3 app has already been updated 6 or 7 times this year. So KP3 is the more reliable app because it is being properly maintained with regular updates whereas the older KP app has not been properly maintained because updates are rare.

Now over to the KP3 displays that I trust. If you click on each of my KP3 images above in turn(or download them for proper image display)-- first the Tablet-KF8-KP3.jpg and then the KindleReader-eInk-KP3.jpg -- then enlarge and compare them you will also note that the image sizes of both versions is exactly the same. And since, in this test, both screen widths and both image widths are the same size -- the screen width does not change for each test on KP3 -- then I would really expect the two image displays to be the exactly same size which was the case in my testing. Which must also ultimately prove that this styling(inline styling using % dimensions) works just fine on both KF7 and KF8 devices. If the styling wasn't functioning correctly in the KF7 version then the KF7/KF8 image displays would not be the same size. Right? But they are the same size...

It's also plain to see that you only tested the epub on the old KP app. And you obviously haven't yet tested that epub on the newer KP3 app. I've now shown you that the KF8 and KF7 displays on the KP3 app are the same size(because both screen widths and both images are exactly the same size) on my tests which was the expected result. This directly conflicts with your own test results on the old KP app(which I have never really trusted).

You could of course actually try loading the mobi version of the test epub into your old eInk device and have a look. But, unfortunately, there is no way that I can see how you could accurately measure the image width(ie by measuring the larger but invisible white canvass background) on your device accurately. Over to you.

I hate to break it to you, William, but we don't use the KP3 app, here at my company. (Other than for Fxl file previews). Why? Because it is NOTHING like the real devices--any of them. It's NOTHING like the PPW/Voyage/Oasis devices, nothing like the Fire. AT ALL. I mean, it is crazy-wrong. We have to have this freaking conversation with Mac user clients, who dl that STUPID app, all the time, about how what they're seeing has no basis in reality. You're using it to guide what you're doing, programmatically and coding-wise, around Kindle? Jesus, no wonder your mindset is screwed up.

And THAT's what you're basing this one? I have other news for you: the "Kindle eReader" emulation, on the KP3, that you are placing all this faith in, as a "good" emulation of a KF7?

It's not a KF7 emulation AT ALL. Not one iota.

It's intended to be emulating the PPW/Oasis/Voyage devices, WHICH ARE KF8.

I literally cannot believe that this entire discussion, this entire disagreement, is based on this totally incorrect misapprehension of yours. I'm NOT going to sit here and try to convince you of this--email Amazon. Go right ahead. I cannot BELIEVE that I've wasted all this time, because you made a totally incorrect assumption about what is what in KP3. Email them, and waste your and their time, since they made this POS app. I've wated enough of mine on this.

There IS no KF7 emulation on the KP3. Not at all.

Didn't you notice, William, that the "Kindle e-reader" emulation, on KP3, has FONTS? Which, we all KNOW, are not available on KF7? What, you saw that and decided it was KF7, any-damned-way?

Jesus, what a freaking waste of our time.

And no--I'm not going to sit here and take screenshots off devices, just to prove it to you. I've already sat here, done all this "testing," took screenshots, etc., because you made an assumption, that not only was totally wrong, but was completely and totally counterindicated, if you had JUST LOOKED AT THE OPTIONS ON THE EMULATION. Like FONTS!!!

You want to be a programmer? Around Kindle devices? Then bloody BUY ONE. This is an absurd, annoying, infuriating waste of my time.

FFS!

I'm now officially and totally DONE with this discussion. UNFREAKINGBELIEVABLE!!!


Hitch

[slowsmile]

@Hitch...You are right about what you say. My sincerest apologies for that mistake.

And further concerning your wild and unnecessary blast from above, I am also quite relieved about your decision to leave this discussion and will happily comply. And yes, I agree with you, this discussion -- primarily about whether an ebook using inline styling with percentage dimensions displays correctly on KF7s -- is going absolutely nowhere...

But if anyone would like to discuss the new plugin(the original purpose of this thread) -- I would be quite happy to discuss that.

[Hitch]

Originally Posted by slowsmile

@Hitch...Just one point from your wild blast above:

Hitch said, referring to the KP3 app:


The following is taken from the KP3's Help doc:



"Not one iota..."? So you're wrong again Hitch.


But if anyone would like to discuss the new plugin(the original purpose of this thread) -- I would be happy to do that.

William:

What the hell is wrong with you? The Paperwhite, Voyage and Oasis are ALL KF8 readers. NOT KF7.

I give up. Go ASK AMAZON. (I'll save you some time. I linked the TECH SPECS, from all three, below, genius.)

FFS. This is hopeless.

ETA: I'm wrong "again?" I am? Have you forgotten that not a week ago, Diap told you that YOU were wrong about KF7 and CSS? Not me? I haven't been wrong, at all. YOU are WRONG here, William. The eInks that you are blathering on about are KF8 devices. Not KF7. And for the LAST goddamn time, if you don't believe me, ask Amazon. Hell, for that matter, ask anyone else HERE, because they ALL know that they're KF7. No wonder you're so screwed up about CSS, etc. Jesus.

Here, genius: since you REFUSE to believe me, maybe you'll believe these guys. AFTER all, they're MEN: http://epubsecrets.com/media-queries...le-devices.php . Scroll down. See PAPERWHITE?

This is the most unfreakingbelievable "argument" I've ever been in. UNFREAKINGBELIEVABLE. It's like trying to have a discussion with a goddamn Holocaust denier. "Oh, see, this list of Kf8 devices PROVES that you're wrong, Hitch!"

How about, the FACT that those devices SHOW FONTS PROVES YOU'RE WRONG, WILLIAM!!!????

I am absolutely gobsmacked at how freaking stupid this is. Wasted everybody's time on this, because he doesn't know what devices support WHICH freaking format. UNF*CKINGBELIEVABLE!

From AMAZON's OWN WEBPAGES:


Scroll down, here, under "Technical Details" for the Paperwhite:

https://www.amazon.com/dp/B00OQVZDJM...s_eink_mt#tech and read, under "Content Formats Supported:"

Kindle Format 8 (AZW3), Kindle (AZW), TXT, PDF, unprotected MOBI, PRC natively; HTML, DOC, DOCX, JPEG, GIF, PNG, BMP through conversion

Or, how about this, for the Voyage: https://www.amazon.com/dp/B00IOY8XWQ...ds_erd_ic#tech

Kindle Format 8 (AZW3), Kindle (AZW), TXT, PDF, unprotected MOBI, PRC natively; HTML, DOC, DOCX, JPEG, GIF, PNG, BMP through conversion

And last, but not least, the oasis:

https://www.amazon.com/dp/B00REQKWGA...s_erd_wky#tech

Kindle Format 8 (AZW3), Kindle (AZW), TXT, PDF, unprotected MOBI, PRC natively; HTML, DOC, DOCX, JPEG, GIF, PNG, BMP through conversion

Now, since those are the goddamn TECHNICAL DETAILS, from AMAZON, itself, will you shut the hell up about how I'm "wrong,"? Or are you actually going to sit there and look even worse than you already do?

All three of those are KF8, LIKE. I. SAID.


Hitch

[Turtle91]

I was just about to jump in here pointing out slowsmile's error...but he apparently saw it and deleted the majority of his post.

So back to the original (plugin) question - and in conclusion (I think) -

KF7 % for image width = bad, and putting a percentage for the width (inline or not) that is supposedly calculated for the perfect screen width is useless as it doesn't work. Just put the pixel width/height if it is smaller than the screen.

KF8 % for image width = good, and you certainly don't need to put said percentages as an inline style for KF8 (leave them in the CSS), and said percentages certainly don't need to be calculated to match a specific screen width - you just set 80% when you mean 80%.


So, if the calculated percentage doesn't work on KF7, and you don't need a calculated % for KF8, then what exactly does this plugin DO for those who use Sigil to build ePubs?

[slowsmile]

@Turtle91...Thanks for your question and its a good question(though off-topic). In my discussions with Hitch I was actually trying to determine whether using inline styling with % dimensions would actually work on KF7 devices. I asked this question because the eInk displays on the older KP app showed that the test image image(a hawk) displayed correctly as far as I was concerned. That was what our discussion was really all about.

And you needn't worry about how my plugin works because my plugin adds media queries in the accepted way and also dual formats all the images in the ebook for KF7(in pixels) and KF8(as a %) devices. Hitch has also said that the plugin, which she has tested, works fine. Just to also add that Hitch requested this plugin -- she's a professional formatter -- so you should perhaps just accept that this is the proper way to format images for KF7 and KF8 devices in an epub.

If you want to test the new plugin(which hasn't been released yet) just to check and test it for yourself then the download is here on this thread:

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

Also, for more info on its features -- you should read the README file that is inside the downloaded plugin zip file.

I also note that Hitch is still blasting -- even after I apologized...Well, well...

[slowsmile]

@Hitch...I changed that post because I was wrong about the KP3 app displays. I also apologized to you for that mistake. Read it again. This is my last to you on this thread...