Calculating and inserting image width. A plugin?

[DiapDealer]

Rather than an Edit plugin, I'm still of the opinion that people should be writing Output plugins to accommodate this exact sort of scenario. That way, you can keep one standard (and spec-compliant) epub, and then run an Ouput plugin that saves a copy of the epub that is tailored to deal with the quirks of: KDP, Smashwords, iBooks, etc...

Creating Edit plugins that diddle the epub for non-epub reasons doesn't make any sense to me. It means people have to maintain multiple epub versions of the same book to accommodate the various vendor/platform quirks. Using Output plugins would allow content creators to keep one master epub and then squirt out vendor-specific versions on demand.

If this images-need-inline-dimensions-in-percentages thing is a consistent expectation of EPUBs bound for KDP/Kindlegen, then it needs to be part of a KDP Output plugin IMO.

[roger64]

Hi

As slowsmile told us, some kind of relative calculation can be quite useful for Kindle users. I think this usefulness is not limited to Kindle users because it can also provide a very simple and precise way of displaying images for any Epub. As I wrote above, I make exclusive and systematic use of it with Koreader and with Prince PDF, with consistently good results.

As it can be of general use, one could wonder if the result of this calculation could not be included in the Sigil report tool for image files. Currently, this Sigil report namely informs the user about the size of the image, its width and height (in px), and its number of pixels (?).

Could we change this last column or just add a new one to indicate the "advised screen size" in percentage? (It could also be named "advised relative width" or any other name). As written on a post above, it would concern only the images whose advised displayed percentage falls under 100%. The purpose of this report is to provide the user with information so this new column would not look out of step with this purpose.

The user would decide what to do next with this information and would have to clean its image tags before using it. This latter task can be done using some plain regex.

Using this inline style is also practical: as it provides a unique individual value for one image, it seems it makes sense to keep it within its img tag so that the user may be able to modify it directly in code view instead of searching its css file to modify its value.

[theducks]

roger64
the size of all embedded images (image files) is in Tools: Reports

[roger64]

Originally Posted by theducks

roger64
the size of all embedded images (image files) is in Tools: Reports

Originally Posted by roger64

As it can be of general use, one could wonder if the result of this calculation could not be included in the Sigil report tool for image files. Currently, this Sigil report namely informs the user about the size of the image, its width and height (in px), and its number of pixels (?).

Could we change this last column or just add a new one to indicate the "advised screen size" in percentage? (It could also be named "advised relative width" or any other name). As written on a post above, it would concern only the images whose advised displayed percentage falls under 100%. The purpose of this report is to provide the user with information so this new column would not look out of step with this purpose.

The user would decide what to do next with this information and would have to clean its image tags before using it. This latter task can be done using some plain regex.

Indeed and I was just saying that this report could be completed. (see bold characters). I put a question mark after the last item (pixels) just to question its general use and I proposed to change precisely this last column.

I must complete this above post: though a regex will be enough to clean every img tag and insert a global percentage inline, it will nevertheless still be necessary to mark manually each image tag with its individual percentage value (to avoid this a plugin has been previously proposed).

[JSWolf]

Originally Posted by DiapDealer

If this images-need-inline-dimensions-in-percentages thing is a consistent expectation of EPUBs bound for KDP/Kindlegen, then it needs to be part of a KDP Output plugin IMO.

Kindlegen should handle it.

[DiapDealer]

Originally Posted by JSWolf

Kindlegen should handle it.

If you're talking about Kindlegen, the Amazon program, you're missing the point entirely (or just being pointlessly obtuse). If you're talking about the Sigil plugin named Kindlegen, then it should only "handle" that which its creator thinks it should handle. Either way, you don't really have a horse in this race, Jon.

[Hitch]

Originally Posted by roger64

Thanks to Doitsu for correcting his warning on EPUB3. As written in the first post I use inline styles within the img tag to express:

style="width:xx%;"

These inline styles are correct both for EPUB2 and EPUB3. They are -for me- the most concise and precise way to do it.

Why?

Why do you think that using that inline will somehow be better than a style in the stylesheet?

Hitch

[KevinH]

I am more worried about creating aspect ratio specific epubs in general. For example, many people read on their phone which may have a 3:4 aspect ratio in portrait mode and a 4:3 ratio in landscape. Similar issues exist with tablets, and of course Desktop machine windows can be almost any width and height that fits on a screen.

By hard coding the aspect ratio into your width calculation, you are penalizing devices if the user decides to rotate their reading mode from portrait to landscape.

There simply must be a way to use css without hard coded width percentages that for images that are taller than they are wide, you use max height 100% (forcing the too tall image to be properly scaled down to the height of the device in its current orientation) and similar css for images that are wider than they are tall, that properly handle the current orientation so that images will fit on one page regardless of which way the device is oriented or what aspect ratio is used.

What am I missing? Isn't this what Turtle91 is espousing? Does it not work properly for some reason?

[Hitch]

Originally Posted by KevinH

I am more worried about creating aspect ratio specific epubs in general. <snippage>

What am I missing? Isn't this what Turtle91 is espousing? Does it not work properly for some reason?

What he said.

Hitch

[roger64]

Originally Posted by KevinH

I am more worried about creating aspect ratio specific epubs in general. For example, many people read on their phone which may have a 3:4 aspect ratio in portrait mode and a 4:3 ratio in landscape. Similar issues exist with tablets, and of course Desktop machine windows can be almost any width and height that fits on a screen.

By hard coding the aspect ratio into your width calculation, you are penalizing devices if the user decides to rotate their reading mode from portrait to landscape.

There simply must be a way to use css without hard coded width percentages that for images that are taller than they are wide, you use max height 100% (forcing the too tall image to be properly scaled down to the height of the device in its current orientation) and similar css for images that are wider than they are tall, that properly handle the current orientation so that images will fit on one page regardless of which way the device is oriented or what aspect ratio is used.

What am I missing? Isn't this what Turtle91 is espousing? Does it not work properly for some reason?

Indeed this 4/3 ratio presumes you'll be reading in portrait mode. Even if it was offered on the Sigil report as a default mode, it should not be seen as a compulsory "same size for all", just like another possibility you give to these portrait mode users . They take it or not. I have no statistics to give you, but I do think they may be a majority among readers...

Using this percentage as an inline style, allows to modify the display very easily. As you use a unique value for each image, I cannot see why it should be better to put it in the stylesheet. The closer this value is from the display, the easier you check it.

[Hitch]

Originally Posted by roger64

Indeed this 4/3 ratio presumes you'll be reading in portrait mode. Even if it was offered on the Sigil report as a default mode, it should not be seen as a compulsory "same size for all", just like another possibility you give to these portrait mode users . They take it or not. I have no statistics to give you, but I do think they may be a majority among readers...

Using this percentage as an inline style, allows to modify the display very easily. As you use a unique value for each image, I cannot see why it should be better to put it in the stylesheet. The closer this value is from the display, the easier you check it.

Sorry, but...I see absolutely no advantage whatsoever to using it inline. If you're using Sigil, why not just click "go to link or style?" Instead of scrolling around?

It's your workflow, so...don't care. I thought there was some technical reason (rendering, devices, something) for doing what you're doing, but there isn't, apparently.

I simply don't understand why you don't just set the width???? In one place, in the CSS? Why not just say img=80%? What is it that the rest of us are missing?

Hitch

[DNSB]

Personally, I tend to use width percentages and height percentages relative to an 600x800 minimum screen resolution so the images appear close to the same size on any of my devices. The samples I've seen in this thread using a max-width expressed in pixels(*). would have my KA1 showing a image less than 50% of the width of the screen while on my old Touch, it would be close to the width and height of the screen (~532x800 for the 626x942 number quoted) if the aspect ratio was maintained.

(*) Pixels like other absolute measurement unit should be banned in ebooks.

[DNSB]

Originally Posted by roger64

Using this percentage as an inline style, allows to modify the display very easily. As you use a unique value for each image, I cannot see why it should be better to put it in the stylesheet. The closer this value is from the display, the easier you check it.

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.

[slowsmile]

@Hitch...The reason you should put the width percentage value in an inline style is specifically to avoid any tinkering of that percentage by -- specifically -- the Kindle overrides in Kindle ebooks. The latter only applies to images in your ebook that are smaller than 100% of the device screen width/height. So if you put your percentage width into an inline style within the image tag(or even in a surrounding div tag) then the Kindle overrides wont be able to find it. Hence no tinkering occurs.

[Hitch]

Originally Posted by DNSB

Personally, I tend to use width percentages and height percentages relative to an 600x800 minimum screen resolution so the images appear close to the same size on any of my devices. The samples I've seen in this thread using a max-width expressed in pixels(*). would have my KA1 showing a image less than 50% of the width of the screen while on my old Touch, it would be close to the width and height of the screen (~532x800 for the 626x942 number quoted) if the aspect ratio was maintained.

(*) Pixels like other absolute measurement unit should be banned in ebooks.

Agreed. But there are some times when there's no choice. If you're making ebooks for Amazon, you have to state pixel sizes on images that are smaller than the full width of the screen in the fallback media queries for KF7. The KF7s don't obey CSS and % widths. So...fallback is necessary.

Originally Posted by slowsmile

@Hitch...The reason you should put the width percentage value in an inline style is specifically to avoid any tinkering of that percentage by -- specifically -- the Kindle overrides in Kindle ebooks. The latter only applies to images in your ebook that are smaller than 100% of the device screen width/height. So if you put your percentage width into an inline style within the image tag(or even in a surrounding div tag) then the Kindle overrides wont be able to find it. Hence no tinkering occurs.

Y'know, William, I don't know why you say that this exists. We've never had a single problem with this, and as you know, we make a LOT of books, and a lot of books with images smaller than 100% of the width of the screen. Why do you think that this occurs?

Hitch