Possible bug/weird behaviour in ACCESS. Strange scaling on covers

arspr · 11-24-2013, 05:27 PM

Another possible issue with sideloaded kepubs (or with another undocumented feature).

I've noticed in that when books have a cover (first html) which is bigger than the aura HD resolution then the image is downsized so it fits in width, BUT, as those covers are usually higher than that screen aspect ratio (3/4), then the bottom of the image appears in a second page. And that simply looks horrible.

Some examples:

First of all. Resolution of the Aura HD. 1080 / 1440 = 3/4 = 0.75. If the ratio of the images is lower than this number then the image is narrower and taller than the 3/4 screen of the Aura HD (or any other eink device I know BTW).
"Las legiones malditas" > 1044/1600 = 0.65 > Width fit. Image split in two pages.
"The Carpet people" > 1523/2297 = 0.66 > Width fit. Image split in two pages.
"Dafne desvanecida" > 1194/1674 = 0.71 > Width fit. Image split in two pages.
"La reina sin espejo" > 542/819 = 0.66 > Height fit. Aspect ratio is kept so width is smaller than the screen. Good rendering.
"The Final Empire" > 580/610 = 0.75 > Perfect fit. (This is a kepubized epub book which I also own as a Kobo account official kepub).

More over in all the previous examples but in "La reina sin espejo", the cover image has a height:100% CSS property. So, as you can see, that setting is being completely ignored (a bug?).

But, in addition, in "La reina sin espejo", there's neither height nor width CSS setting so it should be rendered in its original size which is actually smaller than the screen size. But it isn't.

So, unless I've made some kind of mistake, and always considering that we are talking about sideloaded kepubs where other unknown rules different from epubs might be being applied, it really seems that:

ACCESS is ignoring CSS height and width properties on the cover. ACCESS always makes a 100% (screen size) rendering.
Smaller images than the screen resolution are correctly enlarged. ACCESS performs a height fit which actually works fine.
Bigger images than the screen resolution are wrongly downsized. ACCESS performs a width fit which causes the image to be split in two pages.

(In a quick search on my Calibre library, I haven't found any book with a cover image wider than a 3/4 ratio so I cannot test what happens in that situation).

davidfor · 11-24-2013, 06:00 PM

What is the actual HTML code and CSS that is putting the images into the page?

arspr · 11-25-2013, 10:26 AM

Quote:

Originally Posted by davidfor

What is the actual HTML code and CSS that is putting the images into the page?

Sure. I copy both the relevant code from the html file and the relevant CSS styles. (Once more, again and again, thanks Sigil)

You will notice that some classes are missing, but that's how the books are. I've rechecked twice.

Las legiones malditas

Code:

<body>
  <div id="legion">
    <div class="generated-style">
      <p class="imatge" xml:lang="es"><span class="imatge"><img alt="Legiones malditas.jpg" class="generated-style-2" height="100%" src="../Images/9788466645485.jpeg" /></span></p>
    </div>
  </div>
</body>

Code:

div.generated-style {
}
p.imatge {
	font-family: "StempelGaramondRoman";
	font-weight: normal;
	font-style: normal;
	font-size: 0.88em;
	line-height: 1.29em;
	text-decoration: none;
	font-variant: normal;
	text-indent: 1.62em;
	text-align: center;
	color: #000000;
	margin: 0em;
}

The Carpet People

Code:

<style type="text/css">
.sjfixer { margin: 0; padding: 0; text-align:center;}
</style>
</head>

<body class="sjfixer">
  <p class="sjfixer"><img alt="image" height="100%" src="../Images/MyCoverImage.jpg" /></p>
</body>

That's all, no linked external CSS stylesheet in this case.

Dafne desvanecida

Code:

<style type="text/css">
body { background-color:#000000; text-align:center; margin:0px;}
  img { max-width:100%; height:100%; }
</style>
</head>

<body>
  <div><img alt="dafne-desvanecida." src="../Images/dafne-desvanecida.jpg" /></div>
</body>

Without external CSS file either.

La reina sin espejo

Code:

<!--<link rel="stylesheet" type="application/vnd.adobe-page-template+xml" href="css/page-template.xpgt"/>-->
<style type="text/css">
@page {padding: 0pt; margin:0pt}
            body { text-align: center; padding:0pt; margin: 0pt; }
            div { margin: 0pt; padding: 0pt; }
</style>
</head>

<body style="oeb-column-number: 1;">
  <div class="body"><img alt="cover" src="../Images/cover.jpg" style="padding: 0; margin: 0;" title="cover" /></div>
</body>

Without any external CSS stylesheet. (I suppose that the body style="oeb-column-number: 1" setting points to page-template.xpgt things but, as you can see, I ALWAYS kill page-template.xpgt.

The Final Empire

Code:

<body style="margin-top:0px; margin-left:0px; margin-right:0px; margin-bottom:0px; text-align:center; background-color:#FFFFFF;">
  <div><a id="Cover"></a> <img alt="image" src="../Images/9780575097742_msr_cvi_r1.jpg" style="height:100%; text-align:center;" /></div>
</body>

No external CSS stylesheet either.

davidfor · 11-25-2013, 06:58 PM

Looking at those, none of them look like they would automatically resize the image to fit into the screen. And, trying some in Sigil demonstrated that to be the case. The Sigil preview window didn't resize the image to fit the fit the window. While that isn't a perfect test, it does suggest that the ACCESS renderer is working as designed.

The usual suggestion for coding the cover is something like the following.

Code:

<div>
  <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 476 714" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
    <image height="714" width="476" xlink:href="../Images/cover.jpeg"></image>
  </svg>
</div>

The height and width need to be changed to match the image. When that is done, it resizes the image to the screen perfectly.

Oh, and just as a coincidence, I started reading a purchased kepub shortly after your original post. Its cover had the same problem. The code for the cover is:

Code:

<body>
  <div id="book-columns">
    <div id="book-inner">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <span class="koboSpan" id="kobo.1.1"><img alt="" src="../Images/cover.jpg" /></span>
      </div>
    </div>
  </div>
</body>

Again, nothing tell it to resize here or in the CSS.

arspr · 11-26-2013, 04:44 PM

Quote:

Originally Posted by davidfor

Looking at those, none of them look like they would automatically resize the image to fit into the screen. ...

Unless I'm seriously wrong, as I said in the first post, all the images but "La reina sin espejo" have a height: 100% setting. That is a fit setting AFAIK, isn't it?

Quote:

Originally Posted by davidfor

... And, trying some in Sigil demonstrated that to be the case. The Sigil preview window didn't resize the image to fit the fit the window. ...

At least in my PC, Sigil 0.7.4 seems to have some trouble rendering images which I don't remember from previous versions but I don't feel like downgrading. (A bug in Sigil?) Nevertheless because of all the things that are happening with Sigil, I think that a more confident test is done through Calibre viewer. And I swear that they make a perfect fit in Calibre.

I'm telling a white lie here. They make a perfect fit EVEN in "La reina sin espejo" which actually doesn't have any kind of height setting. In my first post I supposed that in this situation the standard rendering was showing the image with its original size. Maybe the software can actually choose what to do in that case with no explicit setting?

Quote:

Originally Posted by davidfor

... While that isn't a perfect test, it does suggest that the ACCESS renderer is working as designed.

I cannot follow you. Why do you say that ACCESS is doing the expected thing if it is not following an explicit height: 100% setting? As I post it's normally making a perfect width: 100% but then height is 118% (or whatever).

Quote:

Originally Posted by davidfor

The usual suggestion for coding the cover is something like the following.

Code:

<div>
  <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 476 714" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
    <image height="714" width="476" xlink:href="../Images/cover.jpeg"></image>
  </svg>
</div>

The height and width need to be changed to match the image. When that is done, it resizes the image to the screen perfectly.

Oh, and just as a coincidence, I started reading a purchased kepub shortly after your original post. Its cover had the same problem. The code for the cover is:

Code:

<body>
  <div id="book-columns">
    <div id="book-inner">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <span class="koboSpan" id="kobo.1.1"><img alt="" src="../Images/cover.jpg" /></span>
      </div>
    </div>
  </div>
</body>

Again, nothing tell it to resize here or in the CSS.

Again I'm no expert so I am possibly wrong. But look how in your svg code (which is not an img tag but a combination of newer svg and image tags) you have both the size of the image in pixels AND a resizing through height and width 100% plus an aspect ratio preserving setting.

I mean, unless I'm seriously wrong the resizing of the image is always done through the 100% setting which my examples have.

davidfor · 11-26-2013, 09:38 PM

Quote:

Originally Posted by arspr

Unless I'm seriously wrong, as I said in the first post, all the images but "La reina sin espejo" have a height: 100% setting. That is a fit setting AFAIK, isn't it?

At least in my PC, Sigil 0.7.4 seems to have some trouble rendering images which I don't remember from previous versions but I don't feel like downgrading. (A bug in Sigil?) Nevertheless because of all the things that are happening with Sigil, I think that a more confident test is done through Calibre viewer. And I swear that they make a perfect fit in Calibre.

I'm telling a white lie here. They make a perfect fit EVEN in "La reina sin espejo" which actually doesn't have any kind of height setting. In my first post I supposed that in this situation the standard rendering was showing the image with its original size. Maybe the software can actually choose what to do in that case with no explicit setting?

I cannot follow you. Why do you say that ACCESS is doing the expected thing if it is not following an explicit height: 100% setting? As I post it's normally making a perfect width: 100% but then height is 118% (or whatever).

I think there are a couple of problems with the above. One is a mixture of standards. The epub standards are for HTML5. This allows IMG width in percent or pixels but height only in pixels. The height in percent as specified is probably being ignored.

The other problem is what does 100% mean? Full size or fill the containing element?

Quote:

Again I'm no expert so I am possibly wrong. But look how in your svg code (which is not an img tag but a combination of newer svg and image tags) you have both the size of the image in pixels AND a resizing through height and width 100% plus an aspect ratio preserving setting.

I mean, unless I'm seriously wrong the resizing of the image is always done through the 100% setting which my examples have.

If you go to the epub forum here and ask "How do I get my cover images to resize to screen size but maintain the aspect ratio?", you will get the code I posted. With a statement to change the sizes to match the image size. I have played with the IMG tag in the past and never gotten it perfect. With the SVG and IMAGE tags, it works perfectly

I would suggest you read up on the tags and their attributes. It's been a while since I did, but how it working made sense when I looked at it.

arspr · 11-27-2013, 10:44 AM

Well I cannot have a really definite opinion on epubs and img tags as I'm in no way an expert. You are surely right and all the examples I've posted are somehow defective, even if they come from real books!!!

I expected (and I suppose the book editors too) that height:100% should be fine and as you say probably it's not. (BTW: 100% relative to the containing element, so if there were paddings or margins in body, div or p, they should restrict the available area for the image).

But then we return to the final reasoning of my first post. OK, ACCESS is ignoring the img properties because they are defective, against specification or whatever. Even if other apps render they fine, you cannot say ACCESS is buggy because of this decision, because the epubs are already defective.

So, now we have 5 books (one of them, "The Last Empire" coming from Kobo itself...) with no valid image settings in the cover. Then what I really cannot understand is why Kobo is making a height:100% fit when the image is smaller than the screen and a width:100% fit when it is bigger.

The correct decision should have been a height:100% fit when the image was taller and narrower than the available area on the screen and a width:100% fit when the image was shorter and wider.

arspr · 12-04-2013, 11:06 AM

As expected this issue is present in FW 3.1.0

PeterT · 12-04-2013, 01:38 PM

If this issue is only present in USER CREATED kEpubs I don't think you can it a bug.

As I KEEP saying we have ZERO official documentation from Kobo on the format and structures expected within a kEpub formatted book.

DNSB · 12-04-2013, 01:43 PM

Quote:

Originally Posted by arspr

So, now we have 5 books (one of them, "The Last Empire" coming from Kobo itself...) with no valid image settings in the cover. Then what I really cannot understand is why Kobo is making a height:100% fit when the image is smaller than the screen and a width:100% fit when it is bigger.

The correct decision should have been a height:100% fit when the image was taller and narrower than the available area on the screen and a width:100% fit when the image was shorter and wider.

Have you tried using max-width/max-height or a mix instead? Something like max-width=100%; height=auto;? Though I would vote for the svg wrapper technique instead. It simply works better though you will have to wrap your mind around the idea that height/width are just another way of writing the aspect ratio.

As for complaints about what Kobo is doing, this seems to be more an issue with the renderer so either Adobe/DataLogics or ACCESS would be the guilty parties.

I find that quite a few commercial ebooks appear to have been produced by minimum wage earning high school students. One horrible example had 11 <div> tags at the start of the 3 files that the body of the book was broken up into. Most of those divs set font sizing which made it real fun to figure out exactly what the final text size was going to be. Not to mention 20 or so <br> tags to give a gap between chapters with 2 breaks in the middle of chapters for the file breaks.

Regards,
David

arspr · 12-04-2013, 03:56 PM

Quote:

Originally Posted by DNSB

Have you tried using max-width/max-height or a mix instead? Something like max-width=100%; height=auto;? Though I would vote for the svg wrapper technique instead. It simply works better though you will have to wrap your mind around the idea that height/width are just another way of writing the aspect ratio.

As for complaints about what Kobo is doing, this seems to be more an issue with the renderer so either Adobe/DataLogics or ACCESS would be the guilty parties.

I haven't tested any other setting but the original book ones.

And as davidfor says possibly the problem is the out-of-standard height=100% setting. But, every other renderer (Adobe or Calibre) works fine but ACCESS doesn't (Sigil seems defective in 0.7.4). So just as a friendly suggestion to Kobo I would recommend them checking why inferior renderers look better than them.

About the quality (both in obvious final layout and in internal coding) of current ebook editions I do agree with you... They are TOO frequently below the minimum expected level.

arspr · 03-26-2014, 05:28 PM

Unearthing an old thread because as nearly always Kobo DO HAVE BUGS. And this time with the <svg> + <image> procedure.

Quote:

Originally Posted by davidfor

The usual suggestion for coding the cover is something like the following.

Code:

<div>
  <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 476 714" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
    <image height="714" width="476" xlink:href="../Images/cover.jpeg"></image>
  </svg>
</div>

Grab the attached image. It's a real cover from a real book.

Use the following code for the first cover html page:

Code:

<?xml version='1.0' encoding='utf-8'?>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
  <title>Silencio_de_blanca</title>
  <style type="text/css">
  body {
    background-color: #000;
    margin: 0;
    text-align: center;
  }
  img {
    max-width: 100%;
    height: 100%;
  }
  </style>
</head>

<body id="Silencio_de_blanca" xml:lang="es-ES">

  <!-- <div><img alt="" src="../Images/Silencio-de-Blanca.jpg"/></div> -->

  <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="99%" version="1.1" viewBox="0 0 970 1360" width="99%">
    <image height="1360" transform="translate(0 0)" width="970" xlink:href="../Images/Silencio-de-Blanca.jpg"/>
  </svg>

</body>

</html>

As you can see I've commented out the original <img> tag and I've used the <svg>+<image> pair.
Do you see the strange 99% setting in width and height? Reason: try the obvious 100% and you'll see it. You will get a second page on the cover (completely empty but a "line" in the upper part of the screen).

Just another more bug, I fear...

jackie_w · 03-26-2014, 08:06 PM

Is there some reason why you didn't use davidfor's suggested svg code quoted in your post (which BTW is also how calibre codes svg cover images) i.e.

Code:

    <body>
        <div>
            <svg version="1.1" xmlns="http://www.w3.org/2000/svg"
                xmlns:xlink="http://www.w3.org/1999/xlink"
                width="100%" height="100%" viewBox="0 0 970 1360"
                preserveAspectRatio="xMidYMid meet">
                <image width="970" height="1360" xlink:href="../Images/Silencio-de-Blanca.jpg"/>
            </svg>
        </div>
    </body>

Added: You need to wrap <svg> code in <div> tags...
Added2: ... or maybe it's only Sigil which flags an error if you don't.

At least, this seems to work OK for standard epubs on Kobo fw3.2.0. but I don't know whether it also works in kepubs.

arspr · 03-27-2014, 03:46 PM

Quote:

Originally Posted by jackie_w

Is there some reason why you didn't use davidfor's suggested svg code quoted in your post (which BTW is also how calibre codes svg cover images) i.e.

Code:

    <body>
        <div>
            <svg version="1.1" xmlns="http://www.w3.org/2000/svg"
                xmlns:xlink="http://www.w3.org/1999/xlink"
                width="100%" height="100%" viewBox="0 0 970 1360"
                preserveAspectRatio="xMidYMid meet">
                <image width="970" height="1360" xlink:href="../Images/Silencio-de-Blanca.jpg"/>
            </svg>
        </div>
    </body>

Added: You need to wrap <svg> code in <div> tags...
Added2: ... or maybe it's only Sigil which flags an error if you don't.

At least, this seems to work OK for standard epubs on Kobo fw3.2.0. but I don't know whether it also works in kepubs.

Well, probably because I copied the structure from other source (probably other book) where there wasn't a <div> pair in the middle.

Nevertheless I've tested it:

Code:

<body id="Silencio_de_blanca" xml:lang="es-ES">

  <!-- <div><img alt="" src="../Images/Silencio-de-Blanca.jpg"/></div> -->

  <div>

    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" height="100%" version="1.1" viewBox="0 0 970 1360" width="100%">
      <image height="1360" transform="translate(0 0)" width="970" xlink:href="../Images/Silencio-de-Blanca.jpg"/>
    </svg>

  </div>

</body>

and it doesn't work fine either.

As a matter of fact, this is not the first book I suffer with the issue but I was lazy to post it before. (Kobo issues are capable to frustrate the most calmed and relaxed Tibetan monk).

And yes, the trouble is present in ACCESS (kepubs) not in RMSDK (epubs). But the origin of this thread (issues with <img>s in covers) is also an ACCESS only issue.

jackie_w · 03-27-2014, 04:13 PM

OK, I don't use kepubs so I can't suggest any better solution. However, there is still extra code in your 2nd example which was not in the original suggested solution, namely transform="translate(0 0)". I'm no svg expert so it may be completely benign, but I did wonder why you needed to add it.

11-24-2013, 05:27 PM	#1
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	Possible bug/weird behaviour in ACCESS. Strange scaling on covers Another possible issue with sideloaded kepubs (or with another undocumented feature). I've noticed in that when books have a cover (first html) which is bigger than the aura HD resolution then the image is downsized so it fits in width, BUT, as those covers are usually higher than that screen aspect ratio (3/4), then the bottom of the image appears in a second page. And that simply looks horrible. Some examples: First of all. Resolution of the Aura HD. 1080 / 1440 = 3/4 = 0.75. If the ratio of the images is lower than this number then the image is narrower and taller than the 3/4 screen of the Aura HD (or any other eink device I know BTW). "Las legiones malditas" > 1044/1600 = 0.65 > Width fit. Image split in two pages. "The Carpet people" > 1523/2297 = 0.66 > Width fit. Image split in two pages. "Dafne desvanecida" > 1194/1674 = 0.71 > Width fit. Image split in two pages. "La reina sin espejo" > 542/819 = 0.66 > Height fit. Aspect ratio is kept so width is smaller than the screen. Good rendering. "The Final Empire" > 580/610 = 0.75 > Perfect fit. (This is a kepubized epub book which I also own as a Kobo account official kepub). More over in all the previous examples but in "La reina sin espejo", the cover image has a height:100% CSS property. So, as you can see, that setting is being completely ignored (a bug?). But, in addition, in "La reina sin espejo", there's neither height nor width CSS setting so it should be rendered in its original size which is actually smaller than the screen size. But it isn't. So, unless I've made some kind of mistake, and always considering that we are talking about sideloaded kepubs where other unknown rules different from epubs might be being applied, it really seems that: ACCESS is ignoring CSS height and width properties on the cover. ACCESS always makes a 100% (screen size) rendering. Smaller images than the screen resolution are correctly enlarged. ACCESS performs a height fit which actually works fine. Bigger images than the screen resolution are wrongly downsized. ACCESS performs a width fit which causes the image to be split in two pages. (In a quick search on my Calibre library, I haven't found any book with a cover image wider than a 3/4 ratio so I cannot test what happens in that situation). Last edited by arspr; 11-24-2013 at 05:48 PM.

11-25-2013, 06:58 PM	#4
davidfor Grand Sorcerer Posts: 24,905 Karma: 47303824 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	Looking at those, none of them look like they would automatically resize the image to fit into the screen. And, trying some in Sigil demonstrated that to be the case. The Sigil preview window didn't resize the image to fit the fit the window. While that isn't a perfect test, it does suggest that the ACCESS renderer is working as designed. The usual suggestion for coding the cover is something like the following. Code: <div> <svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 476 714" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink"> <image height="714" width="476" xlink:href="../Images/cover.jpeg"></image> </svg> </div> The height and width need to be changed to match the image. When that is done, it resizes the image to the screen perfectly. Oh, and just as a coincidence, I started reading a purchased kepub shortly after your original post. Its cover had the same problem. The code for the cover is: Code: <body> <div id="book-columns"> <div id="book-inner"> <div xmlns="http://www.w3.org/1999/xhtml"> <span class="koboSpan" id="kobo.1.1"><img alt="" src="../Images/cover.jpg" /></span> </div> </div> </div> </body> Again, nothing tell it to resize here or in the CSS.

11-27-2013, 10:44 AM	#7
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	Well I cannot have a really definite opinion on epubs and img tags as I'm in no way an expert. You are surely right and all the examples I've posted are somehow defective, even if they come from real books!!! I expected (and I suppose the book editors too) that height:100% should be fine and as you say probably it's not. (BTW: 100% relative to the containing element, so if there were paddings or margins in body, div or p, they should restrict the available area for the image). But then we return to the final reasoning of my first post. OK, ACCESS is ignoring the img properties because they are defective, against specification or whatever. Even if other apps render they fine, you cannot say ACCESS is buggy because of this decision, because the epubs are already defective. So, now we have 5 books (one of them, "The Last Empire" coming from Kobo itself...) with no valid image settings in the cover. Then what I really cannot understand is why Kobo is making a height:100% fit when the image is smaller than the screen and a width:100% fit when it is bigger. The correct decision should have been a height:100% fit when the image was taller and narrower than the available area on the screen and a width:100% fit when the image was shorter and wider. Last edited by arspr; 11-28-2013 at 01:10 PM.

03-26-2014, 08:06 PM	#13
jackie_w Grand Sorcerer Posts: 6,248 Karma: 16539642 Join Date: Sep 2009 Location: UK Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3	Is there some reason why you didn't use davidfor's suggested svg code quoted in your post (which BTW is also how calibre codes svg cover images) i.e. Code: <body> <div> <svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 970 1360" preserveAspectRatio="xMidYMid meet"> <image width="970" height="1360" xlink:href="../Images/Silencio-de-Blanca.jpg"/> </svg> </div> </body> Added: You need to wrap <svg> code in <div> tags... Added2: ... or maybe it's only Sigil which flags an error if you don't. At least, this seems to work OK for standard epubs on Kobo fw3.2.0. but I don't know whether it also works in kepubs. Last edited by jackie_w; 03-26-2014 at 08:16 PM. Reason: Added:

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Possible bug. Strange page numbering in ACCESS (sideloaded kepub)	arspr	Kobo Reader	30	12-04-2013 07:12 PM
Color Weird behaviour	goldberry	Nook Color & Nook Tablet	2	10-14-2012 04:10 PM
PRS-T1 Strange T1 behaviour ....	carpetmojo	Sony Reader	3	03-24-2012 03:55 AM
Is this a bug? Strange behaviour of Calibre v0.8.24	innogen	Calibre	11	10-30-2011 10:40 PM
Strange Behaviour	poshm	PocketBook	9	12-31-2009 09:39 AM

11-24-2013, 06:00 PM	#2
davidfor Grand Sorcerer Posts: 24,905 Karma: 47303824 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	What is the actual HTML code and CSS that is putting the images into the page?

12-04-2013, 11:06 AM	#8
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	As expected this issue is present in FW 3.1.0

12-04-2013, 01:38 PM	#9
PeterT Grand Sorcerer Posts: 13,306 Karma: 78876004 Join Date: Nov 2007 Location: Toronto Device: Libra H2O, Libra Colour	If this issue is only present in USER CREATED kEpubs I don't think you can it a bug. As I KEEP saying we have ZERO official documentation from Kobo on the format and structures expected within a kEpub formatted book.

03-27-2014, 04:13 PM	#15
jackie_w Grand Sorcerer Posts: 6,248 Karma: 16539642 Join Date: Sep 2009 Location: UK Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3	OK, I don't use kepubs so I can't suggest any better solution. However, there is still extra code in your 2nd example which was not in the original suggested solution, namely transform="translate(0 0)". I'm no svg expert so it may be completely benign, but I did wonder why you needed to add it.