Quote:
Originally Posted by Tex2002ans
There are many awesome advantages of vector images too. Especially Formulas/Equations + Charts/Graphs and all sorts of computer-generated things. (These can be scaled infinitely or zoomed in with zero loss in quality.)
Vector images are not intended for photographs. |
I've well aware of the advantages to them, but there are also a
lot of limitations, they make sense for things like logos & yes charts & graphs for sure, but using them in an eBook that is intended to be read on a variety of devices that may or may not support them, has
low processing power & is generally designed with lower end hardware, & you generally want to conserve processing power to preserve battery life, outweighs it's benefits for this use case IMO. I love vector graphics, don't get me wrong, I just don't think they belong
in an eBook reader.
Just like I thing WEBP images are nice, you can get better compression with less quality loss, but there's a big difference in what the device reading it has to do to see it & that makes putting them in an eBook not ideal either.
It's like if you have an ePub with the highest level of zip compression, it takes a tiny bit longer to open & page turns are slightly slower, & your computer uses a bit more RAM to view it.
WEBP has the same problem & for a device like a kindle, with a
much slower processor, that makes more of a difference. & it impacts the battery life. They save some space, but there's no such thing as a free lunch, there's a cost.
It doesn't matter for a computer or modern phone, but the difference is actually measurable. Now take a device that only has
½GB or
¼GB of
RAM instead of 32-128GBs &
1GHz or
¾GHz CPU instead of 3-5GHz with a
single core instead of 6-32 cores & what is measurable but hardly noticeable on a computer makes a
much bigger difference.
Now if it's just a wrapper designed to work with vector images that's fine, I just don't see why it's
necessary, not that I don't see a use for the technology.
Quote:
Originally Posted by Turtle91
One awesome function is the 'preserveAspectRatio' which, as it states, preserves the images aspect ratio...It prevents an image from getting clipped, or stretched, in the wrong direction...which is a failing of the method repilo mentioned. No matter the orientation of the display, or weather the image is portrait or landscape, the image will display properly on the 'page'. There will be blank space to fill whichever dimension needs it. the 'xMidYMid meet' is one of the options that simply says 'center the image on the available display vertically and horizontally.
The image height and width is not setting, or restricting, the resolution. It is informing the svg shell what the images height and width are. This is used in conjunction with the 'viewbox' setting to determine which portion of the image to display. Most often you want to display the whole image, so you would set the viewbox from the origin (0 0) to the imageWidth imageHeight (as in '0 0 600 889' for an image that is 600 pixels wide by 889 tall). You can focus on only one portion of the image by restricting those coordinates.
|
An example of a part of a Professional ePub that has the images do
exactly what you are talking about with no need for having the dimensions of the image (Which would have been an issue had I done the Extract & Shrink that I have done before deciding to switch to try to get more control with Sigil):
Code:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" lang="en" xml:lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="default-style"/>
<title>The Book Title Here</title>
<link href="../Styles/stylesheet.css" rel="stylesheet" type="text/css"/>
</head>
<body class="nomargin center">
<section epub:type="bodymatter chapter" id="insert1">
<img alt="insert1" class="insert" src="../Images/Insert1.jpg"/>
</section>
</body>
</html>
That's pretty typical of the ones that I've altered before I do anything to it.
In fact before trying to do more with sigil I would take my ePubs, unzip them, rotate all wide images, then batch scale the images to slightly bigger than the largest screen we will be using, convert the non-color images to greyscale to save a few ks since they generally are RGB even though they are greyscale images for some reason.
I generally take a 40MB ePub & turn it into a 6MB ePub by doing just that & convverting ` and ` to ` & ` which usually cuts out 2-8 pages but probably increases the size as it actually consists of 2 more characters in data with the `&`.
The ones I don't do will, just like you said, show the wide image taking up half of the screen because it's aspect ratio is preserved
naturally, without any special code making that happen. If a tall image is not the screen ratio it will have empty space on the side, it won't get clipped or stretched on the kindle at all, & I've only seen that clipping on phone/tablets when the image in
inline with the text. Calibre's ePub Previewer will do that to the
inline images if the window is small, but
not to the ones that are like what I shared, probably why the
Professional publishers use that format... The only difference I see from that extra steps & extra code is centering the image... Which I don't think worth that effort in the slightest.
The one that I split before & after the image:
Code:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="z3998: http://www.daisy.org/z3998/2012/vocab/structure/#" lang="en" xml:lang="en">
<head>
<title>Part 1</title>
<link href="book.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<section epub:type="bodymatter chapter"><div class="main"><img src="../Images/insert_1.jpg"/>
</div>
</section>
</body>
</html>
I think that's pretty close to the Pro one...
Quote:
Originally Posted by KevinH
In the latest versions of Sigil, you can use new find and replace tools to generate a set of proposed "before" and "after" find and replace results as a table and then you can delete the unwanted replacements from the table and just apply the remaining ones.
|
I mean if I'm going to be doing that I can just as easily, probably easier-ly actually, just delete the extra pages I don't need. So adding a more complicated step to prevent an easier step in 1 step forwards & 3 steps back.
Currently I solve the empty page problem with
Code:
Find: <br/><br/></p>
<h1
Replace: </p><hr class="sigil_split_marker" /><h1
But i have a feeling that won't work very consistently.
I've heard the reasons for the SVG Wrapper, & I thank you for helping me understand it, but I'm now confident that it's not something I'm interested in. I'm more concerned with trying to find a way to improve the automation of splitting the images & find a way to automate renaming of pages if possible