Calculating and inserting image width. A plugin?

[roger64]

Originally Posted by DNSB

Personally, I have a mass of image width/height items in my conglomerated stylesheet. After I finish editing a epub, I remove any unused items. Part of my preference is my abhorrence for in-line styles since they make it a total PITA when editing.

Generally, I don't find using a unique value for each image is needed as very often images are repeated (fleurons. flourishes, vignettes, images used with chapter headers, etc.) or the same image size is used for images inserted into chapters.

So at least both of us (not to forget slowsmile) do use percentages to tune our image display. I feel less alone as a portrait man.

There is a common sense way to deal with this:
- if there is an unique percentage width value required for one image, I think it's more handy to use an inline style because you get an immediate control over it. Furthermore, it works faithfully absolutely everywhere (@Hitch, please feel free to tell me if I am wrong).
- if there is a common value for a group of repeated images as DNSB said "(fleurons. flourishes, vignettes, images used with chapter headers, etc.)" it also makes sense to keep this value in the stylesheet.

This is the way I proceed usually: I give first a common value to all images (this can be done also with a CSS class ), and then, when required, go from one individual image to another and correct this value or this class by replacing it with its individual percentage.

I have an example of a book with sixty images. 21 of them will benefit from individual percentages (under 100%) while the remainder are OK with a 100% width. I deal first with all images, giving them all the group percentage (100%), and then for these 21 others I jump from one image to another and change this common value to their individual one.

Whatever may be, I feel there is a need to jump from one image to another every time an image needs an individual percentage. That is the price you have to pay to get a very precise display. That's why it would be very handy:
- if as a minimum Sigil informed me in its report file by calculating which images fall under the "below 100%" percentage. It would do half of the homework.
- ideally if some plugin could automatically insert this individual inline value within the (here 21) images tags which need it. This represents the other half of the homework.

One last remark about "philosophy". I have rather trust my own calculations than rely on the haphazard understanding of various rendering engines in interpreting individual image sizes... I have had too many disappointments on this regard because if anything goes wrong -even a little-, you are unable to correct it easily (at simple view).

[slowsmile]

@Hitch...It's funny that you asked me that question because I'm currently writing a Sigil plugin that will convert all absolute sizing and spacing values(e.g. pts, in, mms, cms, pc) in the epub stylesheet(s) to relative "em" values. So I guess you must be psychic...

...And the answer to your question is very similar. If we are talking epubs, Kindle, as well as other ereader vendors, don't like us using pixels(an absolute measure) for images smaller than 100% of the screen size. Kindle prefers smaller image dimensions as a value relative to current screen width -- in percentages. So if you don't use % values for your smaller images and use pixels instead then your smaller images will be screwed by the Kindle software as I've found with some Kindle conversions in the past. Lesson learned. Always use percentage values for your smaller ebook images for Kindle or it will be changed willy-nilly by the Kindle software viz the Kindle overrides. And as roger64 has said, using % values for smaller images will also work across all ereader types.

In case you get me wrong, what I am inferring is this...If you, me and roger64 can easily calculate the value of a smaller image in pixels and convert this to a % value for Kindle then why can't the Kindle software team do this transformation and simple calculation for us when they display these smaller images on Kindles -- and do it accurately?

[Hitch]

Originally Posted by roger64

So at least both of us (not to forget slowsmile) do use percentages to tune our image display. I feel less alone as a portrait man.

There is a common sense way to deal with this:
- if there is an unique percentage width value required for one image, I think it's more handy to use an inline style because you get an immediate control over it. Furthermore, it works faithfully absolutely everywhere (@Hitch, please feel free to tell me if I am wrong).

As this thread seems to be commingling Sigil, ePUB and Amazon/Kindle, I will say this: your code will NOT work, not at all, for Amazon's KF7 devices, presuming that you're talking about what's in your first post. KF7 utterly ignores any CSS, inline or otherwise, and percentages are utterly worthless. (I honestly don't remember you using fixed pixel widths, and from your comment, above, presumably, you do not.)

<snippage>

One last remark about "philosophy". I have rather trust my own calculations than rely on the haphazard understanding of various rendering engines in interpreting individual image sizes... I have had too many disappointments on this regard because if anything goes wrong -even a little-, you are unable to correct it easily (at simple view).

Originally Posted by slowsmile

@Hitch...It's funny that you asked me that question because I'm currently writing a Sigil plugin that will convert all absolute sizing and spacing values(e.g. pts, in, mms, cms, pc) in the epub stylesheet(s) to relative "em" values. So I guess you must be psychic...

Nah. However, William, ems aren't going to help you with KF7, either, and honestly, I've seen nearly as many issues with using ems for images as I have using any other measurement, and, in fact, more.

...And the answer to your question is very similar. If we are talking epubs, Kindle, as well as other ereader vendors, don't like us using pixels(an absolute measure) for images smaller than 100% of the screen size. Kindle prefers smaller image dimensions as a value relative to current screen width -- in percentages. So if you don't use % values for your smaller images and use pixels instead then your smaller images will be screwed by the Kindle software as I've found with some Kindle conversions in the past. Lesson learned. Always use percentage values for your smaller ebook images for Kindle or it will be changed willy-nilly by the Kindle software viz the Kindle overrides. And as roger64 has said, using % values for smaller images will also work across all ereader types.

Well, firstly, again, "using % values for smaller images will also work across all ereader types" does not work for KF7.

Y'know, William, I have NEVER seen this. Not once have I seen the rendering engines screwing up our images that have % settings (as do all our images). Are you perchance discussing the LITB? Do you have a book where that's happened?

Granted, you can't rely on % settings/CSS altogether. You just can't. You have to create inline sizing, in hard pixels, for KF7, if you have an image that's smaller than 100% of the width of the screen. But that's that. Now, we do that for every single image--every one--that we do, that's smaller than 100%, b/c we have fallback for everything, for KF7, whether it's media queries for the CSS or this, for images. And I have never had a single complaint--in 3500 eBooks--with some client saying that her images were squooshed.

In case you get me wrong, what I am inferring is this...If you, me and roger64 can easily calculate the value of a smaller image in pixels and convert this to a % value for Kindle then why can't the Kindle software team do this transformation and simple calculation for us when they display these smaller images on Kindles -- and do it accurately?

I must confess--since we've had our differences--I'm sort of sitting here, wondering if I should ruin your whole day or not. Letting you sit there and do all that work, only to find out that it's not going to work is a sort of Schadenfreude-potential thing, but....kiddo, Ixnay. You don't want to use ems.

Wanna make a wild guess as to why? Seriously?


Hitch

[DNSB]

Originally Posted by Hitch

Granted, you can't rely on % settings/CSS altogether. You just can't. You have to create inline sizing, in hard pixels, for KF7, if you have an image that's smaller than 100% of the width of the screen. But that's that. Now, we do that for every single image--every one--that we do, that's smaller than 100%, b/c we have fallback for everything, for KF7, whether it's media queries for the CSS or this, for images. And I have never had a single complaint--in 3500 eBooks--with some client saying that her images were squooshed.

I seldom have much to do with Kindle ebooks but what you are saying makes me curious about one item. If I create inline sizing with hard pixels, how does this affect how the image is displayed when moving between various display resolutions? Do we see the same issue I see with pixel sizing in epubs where the image shrinks as the PPI/screen size increases -- a 462x375 image that takes about 77% of the width on a 600x800 display is going to take about 61% of the width on a 758x1024 display, 43% on a 1080x1440 display and down to a meager 33% on a 1404x1872 display.

Does this require treating image sizing differently for KF7/azw/mobi vs. KF8 format?

And perhaps this might be best moved elsewhere. Topic drift at the least.

[Hitch]

Originally Posted by DNSB

I seldom have much to do with Kindle ebooks but what you are saying makes me curious about one item. If I create inline sizing with hard pixels, how does this affect how the image is displayed when moving between various display resolutions? Do we see the same issue I see with pixel sizing in epubs where the image shrinks as the PPI/screen size increases -- a 462x375 image that takes about 77% of the width on a 600x800 display is going to take about 61% of the width on a 758x1024 display, 43% on a 1080x1440 display and down to a meager 33% on a 1404x1872 display.

Yes, of course. If you use hard pixel sizing, for anything, that's what happens. You get a pixel-for-pixel display. If you have a 100px wide image, it will be 50% of the width of a 200px wide display, and 10% the width of a 1000px wide display. That's the problem with hard pixel sizing.

Does this require treating image sizing differently for KF7/azw/mobi vs. KF8 format?

YUP, it sure as hell does, and it's beyond tedious. You haven't lived until you have a book with 987 images (this is a real number, not hyperbole) and they're ALL DIFFERENT SIZES, which means, yes, yes, you have to hand code all those suckers. Every. last. one. (Ok, that part WAS hyperbole.Of course, we bracket-navigated them, doing some resizes, etc., so that we ended up with about 6 different not-full-size sizes, and then coded those, but...man. Lemme tell ya. NO FUN AT ALL.)

And perhaps this might be best moved elsewhere. Topic drift at the least.

Hey, this is MR, AND the Sigil forum, where topic drift is our middle name. :-) We'd have to go far, far further afield before TPTB would move us. FAR. FAR.

(Now watch, just 'cuz I said that, we'll get moved...)

Hitch

[roger64]

Originally Posted by Hitch

Yes, of course. If you use hard pixel sizing, for anything, that's what happens. You get a pixel-for-pixel display. If you have a 100px wide image, it will be 50% of the width of a 200px wide display, and 10% the width of a 1000px wide display. That's the problem with hard pixel sizing.

Hitch

Thanks for your input.

One argument again the use of percentage is falling: whether you use hard pixel sizing or relative percentage width , the display of your image will vary according to the size of your screen. So this argument should not be used to condemn the use of percentage width.

Now the question of format. Though I own a Kindle PW3, I never read any azw book (nor KF8). I put my brand new Kindle in a drawer and waited patiently four months till a jailbreak was released. After that, I only read EPUBs or 9×12 PDF...

As I am not a commercial editor, I'll take care only of EPUBs. To repeat what I already said, percentages width on EPUBs are rendered very precisely with Koreader, these EPUBs can also can be converted so precisely to 9×12 format with Prince PDF (a Sigil and Calibre plugin) that I even use this format to check the display of my EPUBs (namely the images)...

[slowsmile]

Well, Hitch, I must disagree with you again:

As this thread seems to be commingling Sigil, ePUB and Amazon/Kindle, I will say this: your code will NOT work, not at all, for Amazon's KF7 devices, presuming that you're talking about what's in your first post. KF7 utterly ignores any CSS, inline or otherwise, and percentages are utterly worthless. (I honestly don't remember you using fixed pixel widths, and from your comment, above, presumably, you do not.)

Ignores any CSS?...That's one heck of a sweeping statement referring to KF7's. So, from your own rather broad(too broad?) statement above, are you saying that no external CSS calls like text-indent, margin, padding, text-align, font-style, font-weight etc will have any effect whatsoever on an ebook in a KF7 device? Sorry Hitch, but such a loose generalization is just plain wrong.

Second point. Do you know the main advantage of using inline styles?

In html you have external css and internal css. The external css is the stylesheet(s) that is outside the html whereas an internal CSS is defined within the html itself.

What is the main purpose or advantage of using an inline style in the html?

Answer:

Thanks to the cascade of Cascading Style Sheets inline styles have the highest precedence or specificity in a document. This means they are going to be applied no matter what else is dictated in your external stylesheet...

Source: https://www.thoughtco.com/what-is-cs...-style-3466446

So, an inline style (inside a specific HTML element) has the highest priority, which means that it will override a style defined inside the <head> tag, or in an external style sheet, or a browser default value.

Source: W3C Schools https://www.w3schools.com/css/css_howto.asp

The important thing to take away from this is that inline style declarations are the highest priority and will always win over any similar declaration in the external CSS or anywhere else(provided they are inserted after any competing class in the html).

So if an inline style is not in the external stylesheet but is in the html code, and given that your above KF7 generalization is somewhat wrong, isn't it reasonable to assume that inline styles will work on KF7 devices?

[Hitch]

Fine, William.

Why on earth would anyone think that I MIGHT know whereof I speak? In that case, go right ahead with ems. Have fun.

Hitch

[DiapDealer]

Originally Posted by slowsmile

Ignores any CSS?...That's one heck of a sweeping statement referring to KF7's. So, from your own rather broad(too broad?) statement above, no external CSS calls like text-indent, margin, padding, font-style, font-weight, text-align etc will have any effect whatsoever on an ebook in a KF7 device? Sorry Hitch, but such a loose generalization is just plain wrong.

No it's not wrong. KF7 doesn't grok css at all. It's essentially HTML3.2 with a handful of attributes. Margins are left-only (achieved with blockquote no less), there is no such thing as right-margin. Text-indent ... nope. Font-style?? Uh-uh. You get <i> <b> and <tt> tags.

Kindlegen may be able to take some css and convert it into html3.2 that the KF7 rendering system can use, but the rest is just dropped. Hitch is right: no css in an old-style mobi7 kindlebook. Unpack one yourself and see. You basically have height/width attributes for paragraphs and blockquotes for a bit of left margin (nest blockquotes to increase the margin). And that's about the extent of the toolbox you get to work with when formatting a KF7 Kindlebook.

[slowsmile]

@DiapDealer...Thanks for clarifying. But several points come into question here. First you mention that 'height' and 'width' are acceptable in KF7 -- is this only for paragraphs and blockquotes or can they be used for image dimensions? Can we therefore also assume(getting back to the original subject of this post) that using height and width as percentages in an inline style for KF7 will work for KF7s as well as all other ereaders? Or is inline styling also a non-starter for HTML 3.2 ?

[Hitch]

Originally Posted by slowsmile

@DiapDealer...Thanks for clarifying. But several points come into question here. First you mention that 'height' and 'width' are acceptable in KF7 -- is this only for paragraphs and blockquotes or can they be used for image dimensions. Can we therefore also assume(getting back to the original subject of this post) that using height and width as percentages in an inline style for KF7 will work for KF7s as well as all other ereaders? Or is inline styling also a non-starter for HTML 3.2 ?

NO IT DOESN'T!!!!

Sorry: to clarify: KF7 does NOT UNDERSTAND PERCENTAGES. For the last damn time!!


Hitch

[slowsmile]

Thanks Hitch.

[DiapDealer]

Regardless of how you specify your image sizes in your KindleBook source epub/xhtml, they will be reduced to height="xxx" width="xxx" in the old-style mobi (xxx being pixels).

<p height="0pt" width="0pt" align="center"><img src="Images/image00093.jpeg" align="baseline" height="600" width="400"></img></p>

K7 only understands pixel image dimensions. I have no idea if Kindlegen is capable of conversing source percentages to K7 pixels nowadays. I highly doubt it though.

[Hitch]

Originally Posted by DiapDealer

Regardless of how you specify your image sizes in your KindleBook source epub/xhtml, they will be reduced to height="xxx" width="xxx" in the old-style mobi (xxx being pixels).

<p height="0pt" width="0pt" align="center"><img src="Images/image00093.jpeg" align="baseline" height="600" width="400"></img></p>

K7 only understands pixel image dimensions. I have no idea if Kindlegen is capable of conversing source percentages to K7 pixels nowadays. I highly doubt it though.

No, it doesn't, and I wish it would. Believe me, we've suffered with images and KF7. You can't just let them size with percentages, because on the KF7 devices, they'll blow up. ALSO, unless it's been fixed, the Voyage has/had a bug--if you had an image >50% of the size of the screen, but less than 100%, it will blow up to 100%. (That's just...an aside.)

When you code images for "Kindle," you have to set the size for KF8 in percentages, and the size for the KF7 in pixels--period. It sucks, but there it is. I WISH that KF7 would use %, because then we could either just use the same damn CSS, or some type of media-query fallback--but we CAN'T.


Hitch

[roger64]

Originally Posted by Hitch

No, it doesn't, and I wish it would. Believe me, we've suffered with images and KF7. You can't just let them size with percentages, because on the KF7 devices, they'll blow up. ALSO, unless it's been fixed, the Voyage has/had a bug--if you had an image >50% of the size of the screen, but less than 100%, it will blow up to 100%. (That's just...an aside.)

When you code images for "Kindle," you have to set the size for KF8 in percentages, and the size for the KF7 in pixels--period. It sucks, but there it is. I WISH that KF7 would use %, because then we could either just use the same damn CSS, or some type of media-query fallback--but we CAN'T.

Hitch

I just emphasized a part of this above statement which should be kept in mind for all those who wish to convert to and use Kindle formats.

That does not make at all the concept of a near future "percentage plugin" less useful or irrelevant. Bugs in old versions of software should not block any progress. Its use has just to be an informed choice.

For me at least, the advantages of this near future plugin offset these drawbacks. Using an inline percentage width provides you with a very powerful and easy to use tool (one image, one value) to control precisely your image display.

So, an inline style (inside a specific HTML element) has the highest priority, which means that it will override a style defined inside the <head> tag, or in an external style sheet, or a browser default value.

Source: W3C Schools https://www.w3schools.com/css/css_howto.asp