Converting epub to epub

[JSWolf]

Originally Posted by hyegeek

Given my current, quite old, reader, all you say is certainly true. But now that I know more of what I want in a reader, I'm waiting for one that will give me what I want and not just almost what I want. Admittedly Kobo is high on my list, but they are not quite there yet.

Lots of interesting things coming out this year and next, so I'm hoping a new reader is in my near future.

What is it you want that you cannot get currently? What will new Readers bring that you want?

[JSWolf]

Originally Posted by deback

To answer your specific question, Calibre will ignore any settings in those sections that don't apply or are not in the file, so it's no big deal to include them all.

I've used my system on thousands of ebooks. The things I've added to the styling and transform sections include the codes that all or most of the publishers use. As I was working on these books, I would add things to those sections as I came to them. After a while, I had added all that I needed to add. Once in a great while, I'll have to manually fix something that my settings changed incorrectly, but that very rarely happens. Usually, when that happens, the publisher used a code like "nonindent" for all the text paragraphs, so it's always an easy fix.

After I convert an epub, I'll open the file in the editor and run Check Book, plus check all the basic formatting to make sure everything is the way I want it to be (which is the way physical books are formatted). Sometimes, I have to make manual edits for various things, and sometimes, I'll have to reformat everything, due to terrible coding by some publishers. When I reformat everything, I'll copy my template CSS list over the .calibre section in the CSS file and change all classes in the HTML files to my classes (with names that make much better sense than those used by publishers).

Some of the things that I have automatically fixed are:

Remove any line space between paragraphs. Sometimes, I have to manually fix these, of course.

Change all indents over .01em to 1.2em. For the first paragraphs in a chapter, I'll change those indents to zero (and manually fix any that don't get changed during the conversion).

Justify all text paragraphs (I've added all the normal publishers' codes used for text paragraphs to the styling section). Once in a while, I'll have to manually add Justify to the CSS file. It very rarely happens, though. Just depends on the publisher.

Change the line-height to 1.2.

In the Transform section, I've added many errors found by Calibre, so when I do the Check Book routine, I rarely have errors to automatically fix or manually fix. The usual type of error that I still have to automatically fix are ID number errors, which is a quick fix.

To include all the various codes used by all the publishers, I have many entries in both the styling and transform sections. This system has saved me tons of time in the last few years since I set it all up. Thanks to Kovid for telling me how to enter the entries under styling!

I have my rules.txt and styling settings, plus my modify_epub screenshot and an instruction file in a zip file that I would be willing to give to anyone who wants it. Just send me a private message.

I change the indents to 1.2em if they are not already. I drop line-height as that interferes with the line-height slider on my Kobo. I also make sure the base font sizes are all the same. Like offset text being smaller. I use the default font size. I drop the margins so I can use the margin slider correctly. I fix the excess chapter space. I make offset text spacing consistent. I drop any unused CSS. I remove most <p class="someunneededclass"> into just <p>. And there is more. But if you know what you are doing, it doesn't take too long.

[maddz]

Another reason for doing an epub -> epub conversion is to remove 90% of the file size. I get a lot of the Tor.com collections and they generally run upwards of 20Mb for the original epub. Running it through the conversion generally compresses it to less than 10% of that. I suspect it's down to each story in the collection being formatted differently, plus each story has an associated (uncompressed) jpg.

I very rarely go into the editor to fix things. When I do, it's usually to fix OCR errors from poorly converted pdfs (and other pdf conversion issues like page headers). Not having enough time to read as it is, errors have to be particularly bad for me to do this.

[hyegeek]

Originally Posted by JSWolf

What is it you want that you cannot get currently? What will new Readers bring that you want?

That's probably a long conversation that is even more off topic that we've already gotten.

The shorter answer is that while I want a reader and not a tablet, I want quite a few tablet features including using a better reading program that syncs between devices. I also want control over my device (my current device is rooted, I shouldn't HAVE to do that). It also needs to have great battery life (at least two weeks of reading). When I setup my current reader to do most of what I want, the battery lasts only 1 day.

Oh, and don't forget that color e-ink is almost usable...

[JSWolf]

Originally Posted by maddz

Another reason for doing an epub -> epub conversion is to remove 90% of the file size. I get a lot of the Tor.com collections and they generally run upwards of 20Mb for the original epub. Running it through the conversion generally compresses it to less than 10% of that. I suspect it's down to each story in the collection being formatted differently, plus each story has an associated (uncompressed) jpg.

I very rarely go into the editor to fix things. When I do, it's usually to fix OCR errors from poorly converted pdfs (and other pdf conversion issues like page headers). Not having enough time to read as it is, errors have to be particularly bad for me to do this.

The images are being resized because you don't have your options set correctly. Your output profile should be set to tablet so the images do not get resized.

[JSWolf]

Originally Posted by hyegeek

That's probably a long conversation that is even more off topic that we've already gotten.

The shorter answer is that while I want a reader and not a tablet, I want quite a few tablet features including using a better reading program that syncs between devices. I also want control over my device (my current device is rooted, I shouldn't HAVE to do that). It also needs to have great battery life (at least two weeks of reading). When I setup my current reader to do most of what I want, the battery lasts only 1 day.

Oh, and don't forget that color e-ink is almost usable...

I've never found a need for syncing. I just read different books on different devices (H2O & phone). With a Kobo, you don't need to root. It's open enough from the start. You can install KOReader if you want. Battery life on the Libra is good.

[deback]

Originally Posted by JSWolf

I change the indents to 1.2em if they are not already. I drop line-height as that interferes with the line-height slider on my Kobo. I also make sure the base font sizes are all the same. Like offset text being smaller. I use the default font size. I drop the margins so I can use the margin slider correctly. I fix the excess chapter space. I make offset text spacing consistent. I drop any unused CSS. I remove most <p class="someunneededclass"> into just <p>. And there is more. But if you know what you are doing, it doesn't take too long.

I never have to change indents manually, since they are all changed during the conversion (which takes a few seconds per file).

I also change the space above and below the chapter names. 3em above and 2em below. I often have to do this manually, but I have a styling entry for the class "chapter" that does this during the conversion.

I don't use Kobo, and I don't want the lines scrunched together (too close to each other), so making sure the line-height is set to 1.2 is very important.

I also make sure the base font size is the same--and usually a little smaller for the offset texts.

I add space to the left and right margins (30px each) because I can't stand to read text that touches each side of the reader. I want my ePub files to look the way physical books look (when reading).

The conversion automatically deletes any unused CSS, so there's no need to do that manually.

I always use a class for <p>. It makes no sense to use just <p>.

In many cases, I make many various changes, so that's why I decided to automate most of it. And it has saved me tons of time. When I open a book in the editor, most everything that needs to be fixed was fixed during the conversion (which takes a few seconds for each book normally).

I make other manual changes to the cover image when the size is too big or it's not centered. I use a macro to add the class name and height and width of 100% each to the CSS file. I make other manual changes to the TOC, when needed, and I'll fix any other page that needs fixing that didn't get fixed during the conversion. The conversion fixes many of the basic things, which saves a ton of time, when you're fixing many books.

I use ADE to read ePub files, because my laptop sits on my lap, and I only have to hit one key to go to the next page. I can switch to my browser or email or anything at any time, so it's much more convenient than using a little gadget. I use my network and a batch file to copy finished ePubs to my laptop, so it's quick to open any book in ADE, with no need to hook up a little gadget to a USB port or charge the little gadget's battery or have to hold the little gadget while reading.

When I fix books, I drag them into Calibre, and when done fixing, I copy them back to the original folders on my hard drive. Fixing books is the only reason I use Calibre, since my library is all categorized on my hard drive on my desktop computer (and then certain books are copied to my laptop when I'm ready to read them).

[JSWolf]

Originally Posted by deback

I never have to change indents manually, since they are all changed during the conversion (which takes a few seconds per file).

I also change the space above and below the chapter names. 3em above and 2em below. I often have to do this manually, but I have a styling entry for the class "chapter" that does this during the conversion.

Most ePub does not use "chapter" for the class name for chapter headers.

I don't use Kobo, and I don't want the lines scrunched together (too close to each other), so making sure the line-height is set to 1.2 is very important.

In most cases, you don't need to use a line-height of any kind. just find a program that supports setting the line height and the margins.

[quote]I also make sure the base font size is the same--and usually a little smaller for the offset texts.[quote]

Again classes for this can be very different.

I add space to the left and right margins (30px each) because I can't stand to read text that touches each side of the reader. I want my ePub files to look the way physical books look (when reading).

If you find a program that lets you set the margins, then you can keep the margins at 0. ADE (for example) does not let the text hit the sides of the window when the margins are 0.

The conversion automatically deletes any unused CSS, so there's no need to do that manually.

It's just one menu item and done.

I always use a class for <p>. It makes no sense to use just <p>.

It makes very good sense to use just <p>. It means less code. The idea is to keep it simple and that's not as simple as it can be.

In many cases, I make many various changes, so that's why I decided to automate most of it. And it has saved me tons of time. When I open a book in the editor, most everything that needs to be fixed was fixed during the conversion (which takes a few seconds for each book normally).

I make other manual changes to the cover image when the size is too big or it's not centered. I use a macro to add the class name and height and width of 100% each to the CSS file. I make other manual changes to the TOC, when needed, and I'll fix any other page that needs fixing that didn't get fixed during the conversion. The conversion fixes many of the basic things, which saves a ton of time, when you're fixing many books.

I use ADE to read ePub files, because my laptop sits on my lap, and I only have to hit one key to go to the next page. I can switch to my browser or email or anything at any time, so it's much more convenient than using a little gadget. I use my network and a batch file to copy finished ePubs to my laptop, so it's quick to open any book in ADE, with no need to hook up a little gadget to a USB port or charge the little gadget's battery or have to hold the little gadget while reading.

When I fix books, I drag them into Calibre, and when done fixing, I copy them back to the original folders on my hard drive. Fixing books is the only reason I use Calibre, since my library is all categorized on my hard drive on my desktop computer (and then certain books are copied to my laptop when I'm ready to read them).

As for fixes, I prefer to do them myself so I know they are done correctly. It doesn't take long in most cases. I also get rid of excess code such as ePub 3 code that I don't need. This way, in ADE/RMSDK, the page numbers are more accurate as there's less unused code to bloat the page numbering. Ilike to know that the code is clean. A conversion does not leave the code as clean as when I do it by hand.

[Sirtel]

I couldn't care less if the code is clean or nasty or in between. I don't care about epub errors either. In fact I never check for them. The only thing I care about is for the book to look like I want it to look on my ereader. So I fix only those few things that matter to me, like line-height, indents and spaces between paragraphs. The rest I leave as it is. A working TOC is nice to have, but not that important. Generally I won't bother with it.

Still, I do fix these things in the editor, not by conversion. And I delete excerpts, ads, praises, recommendations and other fillers, because I can't stand them. I've never understood the point of excerpts. If I like the author, I'll buy their other works anyway (at least some of them), and if I don't, no amount of excerpts will make me to do so.

[JSWolf]

Originally Posted by Sirtel

I couldn't care less if the code is clean or nasty or in between. I don't care about epub errors either. In fact I never check for them. The only thing I care about is for the book to look like I want it to look on my ereader. So I fix only those few things that matter to me, like line-height, indents and spaces between paragraphs. The rest I leave as it is. A working TOC is nice to have, but not that important. Generally I won't bother with it.

Still, I do fix these things in the editor, not by conversion. And I delete excerpts, ads, praises, recommendations and other fillers, because I can't stand them. I've never understood the point of excerpts. If I like the author, I'll buy their other works anyway (at least some of them), and if I don't, no amount of excerpts will make me to do so.

When I am editing the eBook, I remove all that same rubbish. I also delete any internal. I dump any unused graphics. As long as I'm in the CSS dumping line-height, margins, excessive space for chapter headers, normalizing font sizes, fixing any graphics that need fixing, and other things that make reading better for me, I find that by the time I'm done with what I want, there's not much left (if anything) that could be cleaned up. Sometimes when dumping unused CSS, hundreds of CSS classes get dropped. The last time it as 299 CSS classes that got dropped.

[Sirtel]

Originally Posted by JSWolf

When I am editing the eBook, I remove all that same rubbish. I also delete any internal. I dump any unused graphics. As long as I'm in the CSS dumping line-height, margins, excessive space for chapter headers, normalizing font sizes, fixing any graphics that need fixing, and other things that make reading better for me, I find that by the time I'm done with what I want, there's not much left (if anything) that could be cleaned up. Sometimes when dumping unused CSS, hundreds of CSS classes get dropped. The last time it as 299 CSS classes that got dropped.

I do dump unused css, but leave chapter headers, images etc as is, unless there's something egregiously wrong with them. I just don't want to bother with every little detail, unless the book is a favorite I'm going to read many times. But that's pretty rare, and even then I may not bother with minor details.

[deback]

Originally Posted by JSWolf

Most ePub does not use "chapter" for the class name for chapter headers.

In most cases, you don't need to use a line-height of any kind. just find a program that supports setting the line height and the margins.

If you find a program that lets you set the margins, then you can keep the margins at 0. ADE (for example) does not let the text hit the sides of the window when the margins are 0.

It's just one menu item and done.

It makes very good sense to use just <p>. It means less code. The idea is to keep it simple and that's not as simple as it can be.

As for fixes, I prefer to do them myself so I know they are done correctly. It doesn't take long in most cases. I also get rid of excess code such as ePub 3 code that I don't need. This way, in ADE/RMSDK, the page numbers are more accurate as there's less unused code to bloat the page numbering. Ilike to know that the code is clean. A conversion does not leave the code as clean as when I do it by hand.

Yes, most publishers don't use "chapter," but when they do, I have a styling class for "chapter" that will automatically change the top and bottom margins. No need to manually change them all.

I use ADE and have no desire to use any other program, so I have to make sure the line-height is 1.2. Yes, you can't configure ADE, and it does display the paragraph text very close to the left and right margins. That's why I add 30px to each side.

All of my classes are simple and the class names are created to match what they're used for. A simple <p> is too simple and needs a class name to be efficient, in my opinion. But then I'm a perfectionist...

My conversions are very clean, and since I'm a perfectionist and an expert at editing ePub files, I know when and what to edit manually. My system is set up to do many things automatically, instead of spending lots of time doing manual fixes on basic things that can be fixed automatically in a few seconds during the conversion. If you could see one of my ePub files, I'm sure you would agree that I have a perfect system that takes much less time than the amount of time you spend on average per ePub file.

[deback]

Originally Posted by JSWolf

When I am editing the eBook, I remove all that same rubbish. I also delete any internal. I dump any unused graphics. As long as I'm in the CSS dumping line-height, margins, excessive space for chapter headers, normalizing font sizes, fixing any graphics that need fixing, and other things that make reading better for me, I find that by the time I'm done with what I want, there's not much left (if anything) that could be cleaned up. Sometimes when dumping unused CSS, hundreds of CSS classes get dropped. The last time it as 299 CSS classes that got dropped.

I've seen some CSS files contain over 2,000 classes. It's unreal how dumb some of the publishers are when it comes to creating digital files.

Even though I always open each file in the editor to run Check Book, having the delete-unused-CSS function run during the conversion saves time, even though it doesn't take long to delete them manually. When working with dozens of files at a time, it saves time, and I will always automate anything that saves time.

[DNSB]

Originally Posted by deback

All of my classes are simple and the class names are created to match what they're used for. A simple <p> is too simple and needs a class name to be efficient, in my opinion. But then I'm a perfectionist..

Not sure if I would call myself a perfectionist but most of the p tags I use are simple <p> tags with the stylesheet supplying the style for a basic text body paragraph. I then use modifying styles such as text-indent: 0; for the first paragraph in a chapter or after a scene break. After all, CSS is cascading style sheet.

For my personal use epubs, I'd estimate about 10 minutes to run the appropriate items from my saved search collection. For ebooks I work on for others, I will spend more time but that also generally involves testing on multiple platforms. Did I mention I am really beginning to hate media queries?

[JSWolf]

Originally Posted by deback

I've seen some CSS files contain over 2,000 classes. It's unreal how dumb some of the publishers are when it comes to creating digital files.

Even though I always open each file in the editor to run Check Book, having the delete-unused-CSS function run during the conversion saves time, even though it doesn't take long to delete them manually. When working with dozens of files at a time, it saves time, and I will always automate anything that saves time.

When these publishers create new classes, they add them to the existing house style and it just adds more and more bloat. The idea of keep it simple doesn't seems to apply to most of the big publishers.

Thing is, I could take most of the publisher eBooks and clean up the code so it's well formatted with clean and simple code. It would mean when you buy an eBook, it would be ready to read with no eed for changes (in most cases).