Is there a "fix" or work-around for Kindle doubleing size of small graphics?

[bfollowell]

For a while now, I've found it quite annoying that the Kindle doubles the size of small graphics. I'm not certain if this is a Kindle issue or a mobi issue. Either way, it is highly annoying and I've never really seen a good explanation for why this happens or how to keep it from happening.

I recently converted my epub versions of the Harper Collins Lord of the Rings ebooks to mobi so that I can have them on my Kindle. The problem is that there are a lot of small middle-earth characters that can't be reproduced except as graphics. They're small so that they appear in-line with the text flow. However, these look horrible on my Kindle since it doubles the size of the graphics. There are a lot of similar decorative characters and images that really make this an extremely beautiful, book-like, ebook. Unfortunately, the mobi version on my Kindle is horrible.

I know of no way around this and am hopeful that someone on here may have some insights for me.

Thanks in advance to any assistance anyone might be able to provide.

Sincerely,
- Byron

[wallcraft]

Use hisrc and the Kindle will display the image "as is", see MobiPocket's Image support and display.

[bfollowell]

wallcraft,

Thanks very much for your reply. It does seem like I've seen this one somewhere before. There is one small problem though, it just doesn't work. I've tried it and the images don't appear at all when I change the src reference to hisrc. Is this a mobipocket creator only tag?

Let me explain. Mobipocket Creator hasn't been updated in quite some time and from what little I've messed with it, it isn't very intuitive. I haven't found any "good" mobi creators/editors. I create most of my ebooks in epub using the excellent Sigil editor and then use Calibre to convert to mobi. I am able to create beautiful ebooks easily using this method in every respect except for anythinig that includes small graphics.

So, what I'm wondering is, does this hisrc tag work only with Mobipocket Creator or am I just doing something else wrong? Basically, all I've done is change the src= reference to a hisrc= reference. I haven't "added" anything else. Maybe that's my problem. Maybe I need to leave the src reference and add an additional hisrc reference to the same image.

Anyway, if this only works with Mobipocket Creator, I'm not certain it's worth learning a whole new tool for just a few books when I already have something that is so intuitive and easy to use. Please let me know if this is the case so I can decide if I want to try and start learning Mobipocket Creator.

Thanks.

- Byron

[wallcraft]

I would certainly add src= as well as hisrc= since otherwise it won't work as an ePub.

I assume Sigil is preserving the hisrc in the ePub, so the problem is presumably with Calibre (and might go away if you also include src=).

A simple test, without learning MobiPocket Creator, would be to import your ePub into MobiPocket Reader which will automatically convert it to MOBI (with no editing or metadata options). Then see if this MOBI works better on the Kindle. If that works, you can ask for Calibre to be updated to handle hisrc in ePub to MOBI conversion.

[pchrist7]

Hi bfollowell
Should probably not reply to your post.
I'm too new to this world of eBooks to comment on howto construct an ebook, but want to understand at least a bit.
I bought Fall of Giants at Amazon for my new K3. The K3 was not able to show Ty with a "^" above the y; instead a largish image was used. I contacted Kindle/Amazon CS and got this reply:

"We’ve received information from our technical team stating that, since Ty with a ^ accent mark on top of it is not supported by the Kindle, the publisher has correctly inserted this character as an image. It displays about twice as big as the rest of the text at font size 3.
Please note that, currently Kindle doesn't support accented characters. Images don't change size when the font of text is changed, and leaving the image large means that readers who need larger font sizes are able to read the symbol."

An the other hand I "found" a book in html format, converted to mobi using Calibre. No `´etc on the french words. Converting to RTF, using ... Word (aagh), Calibre to mobi worked. So the K3 CAN show these ( at least some ), but why these differences I wonder ? I just don't understand.
Have a nice weekend,

[HarryT]

Originally Posted by pchrist7

Please note that, currently Kindle doesn't support accented characters.

This is totally untrue; the Kindle supports accented characters just fine. The only problem is that it doesn't support this particular character, which is why it's been inserted as a graphic in the book.

[DMSmillie]

This is something of a guess, so if it doesn't help, my apologies.

Where these character/graphics are used, do the IMG tags include height and width attributes?

I've found that, on the Kindle, if the height and width attributes for an image aren't included, the Kindle will expand the image when it's displayed. So far I've only tested this with larger images (e.g. those which occupy 30-50% of the screen when displayed at the correct size) - these get expanded to fill the screen when no height or width values are provided in the HTML code. I'm just wondering if something along those lines is happening with these characters?

- Donna

[bfollowell]

Originally Posted by DMSmillie

Where these character/graphics are used, do the IMG tags include height and width attributes?

No, they do not. It makes no difference though. You can put whatever you want for those attributes. They're just ignored. Anything smaller than about 40% or 50% of the screen is automatically quadrupeled (doubled in height and width).

I have confirmed that changing the src reference to a hisrc reference does keep this from happening though. My problem now is that I do most of my conversion/creation/editing work in epub using Sigil and then convert to mobi using Calibre. It's losing it somewhere in that process.

If I save the epub from Sigil and then convert using Mobipocket Creator or Kindlegen, it works great. No resizing at all. Of course, many other aspects of the conversion are less satisfying. I'm working to find a happy median.

- Byron

Originally Posted by bfollowell

No, they do not. It makes no difference though. You can put whatever you want for those attributes. They're just ignored. Anything smaller than about 40% or 50% of the screen is automatically quadrupeled (doubled in height and width).

I have confirmed that changing the src reference to a hisrc reference does keep this from happening though. My problem now is that I do most of my conversion/creation/editing work in epub using Sigil and then convert to mobi using Calibre. It's losing it somewhere in that process.

If I save the epub from Sigil and then convert using Mobipocket Creator or Kindlegen, it works great. No resizing at all. Of course, many other aspects of the conversion are less satisfying. I'm working to find a happy median.

- Byron

You should probably post that in the calibre forum. I bet you will get a reply soon whether it is a bug or whether you need to change a setting. If it is a bug, it will most likely get fixed soon once it is reported.

[DMSmillie]

Originally Posted by bfollowell

No, they do not. It makes no difference though. You can put whatever you want for those attributes. They're just ignored. Anything smaller than about 40% or 50% of the screen is automatically quadrupeled (doubled in height and width).

That's not entirely true. However your reply made me do some more testing, particularly in relation to the use of the "hisrc" attribute, and in Calibre's conversion to MOBI format.

What I've found:

1. If you don't use the "hisrc" attribute as well as the "src" attribute, you do need to have the image height and width attributes specified, for the Kindle. If you don't, and the image fills less than 25% of the screen, it will be expanded to twice the height and width of the original. If you do specify the image height and width, it will be displayed correctly. See attached "testimagesizesnohisrc1.jpg" and "testimagesizesnohisrc2.jpg".

2. If you do use the "hisrc" attribute, the Kindle will use that rather than the "src" attribute, and will display that image without expanding it. See attached "testimagesizeswithhisrc.jpg".

(The MOBI files for these screen shots were created by running two almost identical HTML files through Kindlegen - the only difference between the two HTML files was that one included the "hisrc" attribute in each IMG tag, whereas the other didn't.)

3. Calibre, when converting to MOBI format, appears to be discarding the "hisrc" attribute, and also discarding the image height and width attributes. I used Calibre to create a MOBI file from an EPUB in which the HTML included "hisrc", "height" and "width" attributes, and then to convert the MOBI to OEB. When I examined the resulting HTML, all three attributes had gone.

Edited to add:

Update: As Kovid indicated, Calibre was retaining image height and width attributes, but changing them to "em" values, rather than pixels (I discovered that the OEB output wasn't actually showing the exact HTML inside the MOBI file - now I use mobiunpack.py to see that accurately). Kindle ignores height or width values in ems inside the IMG tag. Calibre now leaves the IMG height and width attributes in their original form (height="yy" width="xx") when converting to MOBI format.

end of edit

- Donna

[kovidgoyal]

calibre most definitely does not discard height and width attributes. It converts them to ems.

[DMSmillie]

When Calibre converts a book to MOBI, it removes, as far as I can tell, the HTML height and width attributes from the IMG tag. If Calibre is converting image height and width attributes to ems, it must be replacing the HTML attributes with CSS properties, since the HTML attributes only accept, as far as I know, numerical values which indicate height and width in pixels.

For most height and width attributes - those which are deprecated in (X)HTML and therefore not acceptable in the "Strict" flavour - converting from HTML attributes to CSS properties is absolutely fine. The thing is... to the best of my knowledge, the HTML "height" and "width" attributes for the IMG tag aren't deprecated, and if that's the case, they shouldn't really be replaced with CSS formatting. They define the physical dimensions of the image, in pixels.

Yes, it's possible to use CSS to specify an image size in ems if you want the image to scale according to the font size, but I'd suggest that, in most cases, that's not what's wanted - you want the image to be displayed using its "native" dimensions.

- Donna

[kovidgoyal]

no, calibre leaves width and height attributes, in ems. I have since changed that to px since Amazon's MOBI renderer, unlike the original MOBI rendered doesn't handle sizes in ems.

[wallcraft]

Originally Posted by kovidgoyal

I have since changed that to px since Amazon's MOBI renderer, unlike the original MOBI rendered doesn't handle sizes in ems.

This is in the next release?

[kovidgoyal]

Originally Posted by wallcraft

This is in the next release?

yes .