Question on "Live CSS"

[davidfor]

Originally Posted by deback

Converting the file to fix one thing takes one click. Editing the file to fix the margin takes more than one click. How is it "much" easier to edit the CSS than it is to convert?

Because JSWolf doesn't like what the conversion does to the internals of an epub. He would need to go through it and "fix" things.

The answer here is to do what works for you. I would suggest playing with the conversion options in case the defaults change something in ways you don't like.

[JSWolf]

Originally Posted by deback

Converting the file to fix one thing takes one click. Editing the file to fix the margin takes more than one click. How is it "much" easier to edit the CSS than it is to convert?

Because it's very simple process and I don't have to go checking the options to see if I have them set correctly. Plus, I can do it in the time in takes to convert.

[Divingduck]

... and a calibre user can learn a bit more about how ebooks works, how easy it is to modify ebooks and by this way expand own capabilities.

It is less destructive (in respect to conversion) and makes fun too. Sure, you will spend in the beginning (a bit) more time in a learning curve, but in the end you'll be much faster and don't waste time with endless try and error experiences ( ... and never knowing why things are going wrong).

Not all times a bad thing

[theducks]

Originally Posted by Divingduck

... and a calibre user can learn a bit more about how ebooks works, how easy it is to modify ebooks and by this way expand own capabilities.

It is less destructive (in respect to conversion) and makes fun too. Sure, you will spend in the beginning (a bit) more time in a learning curve, but in the end you'll be much faster and don't waste time with endless try and error experiences ( ... and never knowing why things are going wrong).

Not all times a bad thing

You only change what you need to. Conversion introduces other (even if minor) changes. A well formatted book, take only a dozen seconds to adjust to your liking. A poor, or multiply converted book can thake a half-hour to untangle.

[deback]

It's amazing how many settings you can configure in Convert to make the changes you want to make. My converted files come out looking great, but I took the time to learn more about the settings, especially under Look and Feel - Styling and Transform. Convert actually fixes more things than it breaks, and if your settings are configured correctly, there should be no damage to your files from running Convert.

I've saved tons of time, with superb results. I just wish Convert would automatically fix certain errors that it will automatically fix when running Check Book (like the ID and mimetype errors).

I run the Modify plugin first to do many things, and then I run Convert to do the rest. Then I run the editor to check the book and automatically fix the errors, then I'll manually fix the errors that have to be done manually, and then I'll edit the TOC in either the editor or will usually run the TOC plugin to fix multiple epub files. Then I'll use the EpubMerge plugin to create omnibuses and repeat the above steps on the omnibus file. The results are fantastic and are especially great for e-readers and devices that have no default formatting.

There are always files that are poorly coded, so I will spend time manually reformatting some of them. Actually, almost every epub has something wrong with it, but the modify and convert (with the proper settings) will fix most of the problems,, depending on how well the file was created.

[JSWolf]

Originally Posted by deback

It's amazing how many settings you can configure in Convert to make the changes you want to make. My converted files come out looking great, but I took the time to learn more about the settings, especially under Look and Feel - Styling and Transform. Convert actually fixes more things than it breaks, and if your settings are configured correctly, there should be no damage to your files from running Convert.

I've saved tons of time, with superb results. I just wish Convert would automatically fix certain errors that it will automatically fix when running Check Book (like the ID and mimetype errors).

I run the Modify plugin first to do many things, and then I run Convert to do the rest. Then I run the editor to check the book and automatically fix the errors, then I'll manually fix the errors that have to be done manually, and then I'll edit the TOC in either the editor or will usually run the TOC plugin to fix multiple epub files. Then I'll use the EpubMerge plugin to create omnibuses and repeat the above steps on the omnibus file. The results are fantastic and are especially great for e-readers and devices that have no default formatting.

There are always files that are poorly coded, so I will spend time manually reformatting some of them. Actually, almost every epub has something wrong with it, but the modify and convert (with the proper settings) will fix most of the problems,, depending on how well the file was created.

In most cases, a modify ePub followed by the editor and not that difficult. Sometimes it's very easy. I do not like converting ePub > ePub unless I have to. I find the tools in the editor make it very easy to fix things. Plus I have some plugins that work very well like epubcheck and the toolbag. When you remove unused CSS, you get a much smaller CSS that can be worked with a lot easier. Plus, the advantage is that you learn how these eBooks are made and you get better are modifying and you learn more about HTML/CSS for eBooks. It's a win/win. Also, I replace generic covers and delete the crud such as the internal ToC, any reviews, list of books from the author, and other worthless crud. And losslessly compressing the images means I get smaller images. Also, if there are embedded fonts, I remove the ones I don't want and any left I subset. So when I'm done, I have a smaller eBook.

[retiredbiker]

Originally Posted by deback

...and then I'll edit the TOC in either the editor or will usually run the TOC plugin to fix multiple epub files. ...

Hunting for chapter headings in a poorly made book is one of the most tedious tasks, and I can't imaging a way to automate it. When chapter breaks are buried at random in large files, have no common text (like the word "chapter"), and have no unique styling, or inconsistent styling, it can mean an hour or more of scrolling through to find them all.

Once I do find them, I make each chapter a file with split and merge, get each one with the same heading style (which I often have to create), and let the TOC editor build the TOC from the files. Smaller files work better on my Kindle, too.

If there are something like 100+ chapters--that quickly makes it a candidate for "start over" in LibreOffice!

[deback]

This is how I automate it:

Do a regex search for the following (be sure to change the mode to Regex in the dropdown box):

>(\d+) (You might have to add a space before the (\d+), depending on the original coding.)

This might find all the chapter numbers, when the word "chapter" is not included anywhere. Then you can do a find and replace to replace the class with the "chapter" class.

Example (after you've found the class that was used; there could be inconsistent classes used by the creator, which is common):

Find the following: <p class="calibre_3">(\d+)</p>

Replace it with this: <p class="chapter">\1</p>

-or, if you prefer, replace it with the following:

<p class="chapter">Chapter \1</p>

Then go into the ToC editor, click on Generate ToC from XPath. Set up a macro to insert the following on the top Level 1 ToC line (mine is ctrl-shift-T -- or you can type it or you can fill out the lines on the next screen after you click on the wand at the right):

//*[re:test(@class, "chapter", "i")]

Then the Toc Editor will create entries for each chapter.

Create a CSS class for "chapter" to look the way you want it to look.

Here's mine:

.chapter {
display: block;
font-size: 1.4em; (this could change depending on length of the chapter title)
font-weight: bold;
text-align: center;
margin-bottom: 2em;
margin-left: 0;
margin-right: 0;
margin-top: 3em;
}

Convert the file again to have all the chapters start on a new page. You don't have to do this manually. You don't even need the line page-break-before: always; in your "chapter" class, because Convert will do it automatically.

[retiredbiker]

Originally Posted by deback

This is how I automate it:

Do a regex search for the following (be sure to change the mode to Regex in the dropdown box):

>(\d+) (You might have to add a space before the (\d+), depending on the original coding.)

This might find all the chapter numbers, when the word "chapter" is not included anywhere. Then you can do a find and replace to replace the class with the "chapter" class.

Example (after you've found the class that was used; there could be inconsistent classes used by the creator, which is common):

Find the following: <p class="calibre_3">(\d+)</p>

Replace it with this: <p class="chapter">\1</p>

-or, if you prefer, replace it with the following:

<p class="chapter">Chapter \1</p>

Then go into the ToC editor, click on Generate ToC from XPath. Set up a macro to insert the following on the top Level 1 ToC line (mine is ctrl-shift-T -- or you can type it or you can fill out the lines on the next screen after you click on the wand at the right):

//*[re:test(@class, "chapter", "i")]

Then the Toc Editor will create entries for each chapter.

Create a CSS class for "chapter" to look the way you want it to look.

Here's mine:

.chapter {
display: block;
font-size: 1.4em; (this could change depending on length of the chapter title)
font-weight: bold;
text-align: center;
margin-bottom: 2em;
margin-left: 0;
margin-right: 0;
margin-top: 3em;
}

Convert the file again to have all the chapters start on a new page. You don't have to do this manually. You don't even need the line page-break-before: always; in your "chapter" class, because Convert will do it automatically.

Excellent information, thank you!

For consistent chapter headings that are numeric, have an actual unique style, or even are Roman numerals...yes, I search much as you suggest. The ones I find most aggravating are these:

<p class="calibrex">end of a chapter text...</p>
<p class="calibrex">Mary Goes to Market</p>
<p class="calibrex">On Monday Marry walked to the village...</p>

Where the middle line is actually a chapter break - un-numbered, un-identified. Sometimes it's all caps and [A-Z]{3} or something will help, but these just take time.

On the other hand, spending time looking at the text will often find the odd goof, like a dozen random paragraphs in the middle of the book that are strangely styled, so it's not all bad!

Interesting about the "pagrbreak..." lines. I always take them out, since they cause a blank screen, sometimes two, on the Kindle when reading. But then, I always have each chapter start a new file, which gives a clean break with no blank page. But it sounds like a re-convert will do that file splitting automatically. But will it get rid of "orphan" files that are just pieces of chapters? (I'm a neatnik, I guess.)

Thanks for the XPath example. I've not yet explored this, and just looking at the pop-up help frankly scared me off. I'll try this on my next TOC fix-it job. It looks like the "i" picks up the \1 and increments? Is that right? Then I could take a book with 102 chapters in those **&@^%# Roman numerals and easily convert them to arabic numerals?

[deback]

But will it get rid of "orphan" files that are just pieces of chapters?

It will split up a file only when the file is larger than the maximum size in the Convert settings. I don't think it will combine smaller files into one file, which would have to be merged manually.

Thanks for the XPath example. I've not yet explored this, and just looking at the pop-up help frankly scared me off. I'll try this on my next TOC fix-it job. It looks like the "i" picks up the \1 and increments? Is that right? Then I could take a book with 102 chapters in those **&@^%# Roman numerals and easily convert them to arabic numerals?

I have to confess that I got that "chapter" string from what Calibre generated after I clicked on the wand (a long time ago) and read the instructions on what to enter into each line. The top line is either 'p' or 'h1,' etc, the second line is 'class,' and the third line is 'chapter' (in my case, it's 'chapter,' since that's the class name I always use for chapter titles). Then I added the macro to my MacroMaker macro software, so it's real quick now to create the ToC that way.

I almost always change the Roman Numerals in the ToC by highlighting all the chapters (whether they say 1, 2, 3, or I, II, III, or the numbers spelled out, like One, Two, Three, etc), right click on them, and then choose to rename them to Chapter 1, Chapter 2, etc. You can do the same thing with Part 1, Part 2, etc. by changing Chapter to Part or whatever you wish. It will default back to Chapter the next time you go to rename the entries.

[retiredbiker]

Originally Posted by deback

I don't think it will combine smaller files into one file, which would have to be merged manually.

I gave it a try, based on your example, and it worked really, really well! The example I tried happened to need a two-level TOC, so I used "chapter" and "subchapter" styles. Perfect indented TOC resulted. Now I have the impetus to explore this in some more depth.

It did indeed split the files correctly on a re-convert, and file size did not seem to matter. I left an "epilogue" as part of the last file, but coded correctly and in the TOC, and after the conversion it was its own file. But it did not connect a couple of those orphans, which I made specifically to test it. It also misses initial pages you might want in the TOC, like a synopsis or an epigraph...but I see how to include them with the styling. Very cool, thank you.