View Single Post
Old 08-09-2017, 08:52 PM   #36
st_albert
Guru
st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'st_albert gives new meaning to the word 'superlative.'
 
Posts: 698
Karma: 150000
Join Date: Feb 2010
Device: none
Quote:
Originally Posted by slowsmile View Post
@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:
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.

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
st_albert is offline   Reply With Quote