Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > E-Book Software > Sigil

Notices

Reply
 
Thread Tools Search this Thread
Old 07-27-2017, 10:21 AM   #16
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 17,456
Karma: 90388224
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
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.
DiapDealer is offline   Reply With Quote
Advert
Old 07-29-2017, 04:37 AM   #17
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 2,171
Karma: 2204557
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
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.

Last edited by roger64; 07-29-2017 at 06:44 AM. Reason: practical
roger64 is offline   Reply With Quote
Old 07-29-2017, 09:52 PM   #18
theducks
Well trained by Cats
theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.
 
theducks's Avatar
 
Posts: 21,083
Karma: 20800854
Join Date: Aug 2009
Location: (The original) Silicon Valley, USA
Device: K4NT, Galaxy Tab 2(RIP)
roger64
the size of all embedded images (image files) is in Tools: Reports
theducks is offline   Reply With Quote
Old 07-30-2017, 02:23 AM   #19
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 2,171
Karma: 2204557
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
Quote:
Originally Posted by theducks View Post
roger64
the size of all embedded images (image files) is in Tools: Reports
Quote:
Originally Posted by roger64 View Post

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

Last edited by roger64; 07-30-2017 at 03:11 AM. Reason: manually
roger64 is offline   Reply With Quote
Old 07-30-2017, 06:35 AM   #20
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 50,384
Karma: 43720217
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Aura H2O, Sony PRS-650, Sony PRS-T1, nook STR, iPad 4, iPhone 5
Quote:
Originally Posted by DiapDealer View Post
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.
JSWolf is offline   Reply With Quote
Advert
Old 07-30-2017, 07:36 AM   #21
DiapDealer
Grand Sorcerer
DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.DiapDealer ought to be getting tired of karma fortunes by now.
 
DiapDealer's Avatar
 
Posts: 17,456
Karma: 90388224
Join Date: Jan 2010
Device: Nexus 7, Kindle Fire HD
Quote:
Originally Posted by JSWolf View Post
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.
DiapDealer is offline   Reply With Quote
Old 07-31-2017, 03:19 PM   #22
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 5,905
Karma: 55146348
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, and NookColor. 2 Droid, 1 Win8 ePUB rdrs
Quote:
Originally Posted by roger64 View Post
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:
Code:
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
Hitch is online now   Reply With Quote
Old 07-31-2017, 03:40 PM   #23
KevinH
Wizard
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 2,616
Karma: 780906
Join Date: Nov 2009
Device: many
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?
KevinH is online now   Reply With Quote
Old 07-31-2017, 04:23 PM   #24
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 5,905
Karma: 55146348
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, and NookColor. 2 Droid, 1 Win8 ePUB rdrs
Quote:
Originally Posted by KevinH View Post
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
Hitch is online now   Reply With Quote
Old 07-31-2017, 06:40 PM   #25
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 2,171
Karma: 2204557
Join Date: Jan 2009
Device: Kindle PW3 (wifi)
Quote:
Originally Posted by KevinH View Post
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.

Last edited by roger64; 07-31-2017 at 06:44 PM.
roger64 is offline   Reply With Quote
Old 07-31-2017, 07:15 PM   #26
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 5,905
Karma: 55146348
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, and NookColor. 2 Droid, 1 Win8 ePUB rdrs
Quote:
Originally Posted by roger64 View Post
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
Hitch is online now   Reply With Quote
Old 07-31-2017, 11:13 PM   #27
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 3,785
Karma: 15026934
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Aura One, Aura H2O, Aura HD, Nexus 7 HD, iPad Air
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 is online now   Reply With Quote
Old 07-31-2017, 11:31 PM   #28
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 3,785
Karma: 15026934
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Aura One, Aura H2O, Aura HD, Nexus 7 HD, iPad Air
Quote:
Originally Posted by roger64 View Post
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.
DNSB is online now   Reply With Quote
Old 07-31-2017, 11:37 PM   #29
slowsmile
Witchman
slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.slowsmile ought to be getting tired of karma fortunes by now.
 
Posts: 240
Karma: 563708
Join Date: May 2013
Location: Philippines
Device: Android S5
@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.

Last edited by slowsmile; 07-31-2017 at 11:39 PM.
slowsmile is offline   Reply With Quote
Old 08-01-2017, 12:29 AM   #30
Hitch
Bookmaker & Cat Slave
Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.Hitch ought to be getting tired of karma fortunes by now.
 
Hitch's Avatar
 
Posts: 5,905
Karma: 55146348
Join Date: Apr 2010
Location: Phoenix, AZ
Device: K2, iPad, KFire, PPW, Voyage, and NookColor. 2 Droid, 1 Win8 ePUB rdrs
Quote:
Originally Posted by DNSB View Post
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.

Quote:
Originally Posted by slowsmile View Post
@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
Hitch is online now   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Maximize Image Width Cyberseeker ePub 19 06-07-2017 03:53 PM
Plugin for inserting endnotes in an epub 2.0 elibrarian Plugins 40 03-16-2017 09:11 AM
Changing image width in the economist goios Recipes 1 04-24-2014 02:29 PM
Inserting a background image roger64 ePub 1 12-28-2012 07:12 AM
ADE bug in calculating width DaleDe ePub 6 01-17-2010 10:33 AM


All times are GMT -4. The time now is 04:51 PM.


MobileRead.com is a privately owned, operated and funded community.