EPUB output

[DaleDe]

Originally Posted by wallcraft

So far as I can tell, Adobe Digital Editions does not rescale images. As a test I used Baby-iLiad256.prc from More display issues on the DR, the attached version has been converting to ePub using Calibre. The MOBI version's images are rescaled to the window size when using MobiPocket's Desktop Reader. However, all the ePub version does in Windows Adobe Digital Editions and Sony eBook Library is crop the image to the screen size.

Does any ePub reader automatically rescale images? This seems to be yet another hole in the ePub specs.

Yes, the Hanlin V3 reader rescales images. (Bebook, EZ Reader, etc). It shrinks the images in portrait mode a little more that I like but in landscape more they are full width (760 pixels) and then split over pages as needed.
Portrait mode may also split images depending where they are on the page although they are shrunk enough to fit on the page if they are near the top. I have asked Jinke to have an image selection view mode to be able to see the entire image and they are considering it.

How big are the various images in your test epub?

edit: in landscape they are not quite 760 pixels. There is a page margin around the image. I estimate something about 700 or a little more.

Dale

[kovidgoyal]

Hmm so perhaps I was wrong, in any case calibre will resize images to the SONY screen size if you use the SONY profile in the future.

You can achieve that effect by using the css

img { width: 100% }

That should resize horizontally as long as the individual <img> tags dont specify a width.

[llasram]

Originally Posted by kovidgoyal

Hmm so perhaps I was wrong, in any case calibre will resize images to the SONY screen size if you use the SONY profile in the future.

You can achieve that effect by using the css

img { width: 100% }

That should resize horizontally as long as the individual <img> tags dont specify a width.

I haven't tested how they work, but it might also be worth trying some combination of the 'width', 'min-width', and 'max-width' properties. If ADE and other renderers respect 'max-width' then could specify "width: 100%" and a 'max-width' of the actual image width in pixels.

[wallcraft]

Originally Posted by DaleDe

How big are the various images in your test epub?

They are sized for the iLiad: 730x935, 730x935, 768x768, and 768x817.

[DaleDe]

Originally Posted by wallcraft

They are sized for the iLiad: 730x935, 730x935, 768x768, and 768x817.

The Hanlin screen will display 600x760 (about 40 pixels at the bottom are used for the page number and battery indicator.)

In portrait mode page three displays the baby and the building down to just below the street lamp (minus the pole). Aspect ratio is maintained. Page 4 continues the building picture with some overlap (it shows about 1/2 the lamp and the pole. It then starts on the continuous gray scale image which is then continue to page 5 along with the 16 level image.

Dale

[kovidgoyal]

Originally Posted by llasram

I haven't tested how they work, but it might also be worth trying some combination of the 'width', 'min-width', and 'max-width' properties. If ADE and other renderers respect 'max-width' then could specify "width: 100%" and a 'max-width' of the actual image width in pixels.

If ADE supports max-width, adding

img { max-width: 100%; max-height: sony reader screen height }

to Override CSS should do the trick. It's a pity CSS doesn't have viewport relative lengths. If it did there would be no need to use the actual screen height any more.

[pepak]

I am not so sure this would do a proper resize.

And it certainly wouldn't help with those "too large to be displayed" images :-(

[kovidgoyal]

Originally Posted by pepak

I am not so sure this would do a proper resize.

And it certainly wouldn't help with those "too large to be displayed" images :-(

Well as I said, in the future calibre will rescale images larger than the sony screen size.

[pepak]

I know. I appreciate that.

[ldolse]

Hi,

I just started converting some .lit files to epub, and I'm noticing some nasty behavior around css. When converted to HTML, lit files make heavy use of <span></span> tags embedded within <p></p> tags. Every single line/paragraph in the entire book is embedded between these tags. A single line or paragraph starts like this:
<p class="MsoPlainText" id="calibre_css_id_533"><span class="calibre_class_2" id="cfs_1100">

The problem comes with the way Calibre handles the CSS generation. Every single tag in the book gets it's own unique id on top of the class. 99% of these ids use the same settings. The ids in the <p> tags are all setting the text-indent and font size, which never changes in my test (so it could be made part of the class). The ids in the <span> tags are setting a handful of font sizes.

Needless to say this makes it impossible to reformat the book using the flexibility of css. I'm also seeing performance issues in some readers as they try to deal with rendering html with thousands of unique ids.

Here are all the tags/classes that were duplicated in a book I just converted:

• calibre_css_id_xxx - 2789 occurrences with same indent, 2810 occurrences with identical font size
• calibre_class_x (span class): 5 occurrences with identical settings
• cfs_xxx - 2872 occurrences setting the same font size
• div.Sectionxx - 41 occurrences setting the same page break

Note the same handling of <p> and <span> tags happens if I use ConvertLit to convert to HTML and then convert the resulting HTML to epub.

Can Calibre just check to see if a given setting has been used in an existing CSS or class before creating a new ID? Seems like this would fix the problem.

If you point me to the section of code where these decisions are made I can see if I can work out any options myself, but that might be beyond my skills at the moment.

Other issues:
Chapter Detection
When I was creating epubs from PDFs I got a decent handle around how chapter detection functioned in that workflow. If it matches the xpath then the chapters get tagged, and I can see the chapters in Adobe DE. I've converted a couple Lit files, one of them split the book into separate HTML files for each Chapter, but no table of contents was created that Adobe DE could see. Is there something that needs to be done to make that happen?

There are no linefeeds in the resulting html file, would be nice to stick in some line feeds after </p> just to make it easier to work with. Some text editors struggle with opening a file with a single line that long as well.

[kovidgoyal]

css handling has already been changed in calibre, but those changes wont be released until 0.6.0 If you're comfortable using the development version of calibre, you could check out the new code.

As for chapter detection, chapter detection works the same no matter what type of source file you have. You just need to adjust the XPath expression accordingly. And note that calibre split HTML files on page breaks not neccessarily on chanpters. By default it inserts page breaks before chapters, so you may not have realized this behavior.

[Aztek]

Made a rookie mistake, all good now.

Many thanks to the creator of this fine program

[starrigger]

Another ePub snafu:

Twice now I have converted (different) files from rtf to html to epub. One was a friend's book ms.; the other was an article from The Atlantic Monthly that I pasted from the online version. The text converts okay, but for some reason Calibre keeps attaching an unrelated book cover to the converted files--the cover for a Cordwainer Smith book that I bought from Baen over a month ago, and which I don't think I performed any conversions on, though I might have corrected the metadata.

I'm attaching the epub here, and also the source zip file. I note that the incorrect cover image is included in the zip file, so somehow when I add these files to the Calibre library, the bogus cover is getting picked up.

Also, you will note in the epub file, that hyphens (in the context of names such as F-15) are being rendered weirdly.

[starrigger]

P.S. Just redid the epub conversion from the original RTF, and the cover problem didn't occur, but the hyphen problem did.

In a conversion to LRF, neither problem occurred.

[kovidgoyal]

The cover inclusion bug will be fixed in 0.6. The hyphen problem is a problem in the HTML itself. If you open the HTML in an edior, you will see that the hyphen character is not correctly encoded. This probably happened either when you pasted it into Word or converted from rtf to html