Nickel won't display secondary font in body text

[foosion]

Originally Posted by DNSB

Probably. For this ebook, my first thought was that someone thought Vellum didn't create complex enough CSS. Oddly, the formatting wasn't that bad, just that the CSS was ridiculously overcomplex.

The one book I've edited with a Vellum CSS was the most ridiculously complex CSS I've ever seen. How anyone thought that was a sensible way to proceed is beyond me. They could have gotten the same appearance with a much simpler CSS.

[DNSB]

Originally Posted by foosion

The one book I've edited with a Vellum CSS was the most ridiculously complex CSS I've ever seen. How anyone thought that was a sensible way to proceed is beyond me. They could have gotten the same appearance with a much simpler CSS.

For the most part, Vellum is not aimed at those of us who would dig into the internals of the ePub.

Vellum's market is mostly indie authors who write their document in Word or other program generating .docx output and then feed the .docx file into Vellum to generate various flavours of ePub output (ePub2/ePub3, Apple, Kindle, Kobo, Nook, Google, generic) with an option for mobi for local testing on Kindle ereaders/apps. For non-ebook uses, you can generate an print ready output file.

As a group, the authors that I have dealt with are more concerned with generating output that will work without requiring them to know about stylesheets, ebook structure, etc. They do care about not generating masses of complaints.

[foosion]

Originally Posted by DNSB

For the most part, Vellum is not aimed at those of us who would dig into the internals of the ePub.

Vellum's market is mostly indie authors who write their document in Word or other program generating .docx output and then feed the .docx file into Vellum to generate various flavours of ePub output (ePub2/ePub3, Apple, Kindle, Kobo, Nook, Google, generic) with an option for mobi for local testing on Kindle ereaders/apps. For non-ebook uses, you can generate an print ready output file.

As a group, the authors that I have dealt with are more concerned with generating output that will work without requiring them to know about stylesheets, ebook structure, etc. They do care about not generating masses of complaints.

What's a good strategy for dealing with cascading divs, each containing multiple classes, and other such complexity?

[DNSB]

For me, I have a collection of saved searches in Sigil that clean up most of the cascaded divs. They also remove almost all of the media queries from the media stylesheet since they are not needed for most ePub ebooks and clean up a good chunk of the unneeded bits in the styles stylesheet. I also dump dropcaps in this process and convert the ornamental breaks to a single <p>

The workflow is:

1. Open the Vellum generated ePub in Sigil.
2. Run the HTML saved search group to clean up the text files
3. Run the Automate List 1 (runs a collection of Sigil tools and plugins)
4. Run the CSS saved search group to clean up unneeded bits from the stylesheets
5. Reformat the CSS stylesheets to multiple line (builtin Sigil tool)
6. Run the Afters saved search group. Cleans up some bits and bobs left by the other tools
7. Replace the code used to display the cover image and add my bits to the stylesheet.
8. Use TagMechanic to remove blank divs, spans and possibly others.
9. Run Automate List 2 and if no errors, it's done.

It takes longer to type that out than to actually do it. I played with using Editor Chains to do much the same in calibre's ebook editor but was just easier to use Sigil.

Looking at my saved search names, call me boring.

[foosion]

Not a trivial number of changes. If I run into another Vellum monstrosity I may bother you for a copy of your saved searches and automations, if that's not a problem.

Dropcaps should be dropped. I don't mind "* * *" breaks or something equally inoffensive.

[ZodWallop]

For my own adjustment, I have taken some PDFs from Open Library and have converted them to ePubs. Having done this, I've generated my own stylesheet. Considering I'm self taught, I think I've done pretty well.

[Aleron Ives]

Maybe we need a "share your e-book cleanup scripts" thread of some kind.

[foosion]

Originally Posted by Aleron Ives

Maybe we need a "share your e-book cleanup scripts" thread of some kind.

Good idea, if you're serious and I'm not missing an existing thread. There's the search-replace-regex sticky, but that's not the same.

[JSWolf]

Originally Posted by Aleron Ives

Maybe we need a "share your e-book cleanup scripts" thread of some kind.

A lot of eBooks are different enough that a cleanup script may not work well enough.

[foosion]

Originally Posted by JSWolf

A lot of eBooks are different enough that a cleanup script may not work well enough.

One could post a general approach, such as

Run check, do auto cleanup and anything obvious
Remove unused CSS
Fix HTML

Go through file browser, hitting at least each file type (title page, copyright, chapter, etc.).
If you don't like appearance, figure out what's causing it and change. Have a set of rules, such as non-massive headings (1.4em), less empty space above and below headings and sections (margin: 0.5em 0), left justify, no dropcap or the like, 1.4em indent, 0 left right margins.
Eliminate unwanted files (more praise for). Possibly move intro to end. Edit TOC to conform.

Repeat run check, remove, fix. This time through put more effort into fixing errors.

Focus on nice book appearance rather than clean code. Some of this could probably be scripted.

[JSWolf]

Originally Posted by foosion

One could post a general approach, such as

Run check, do auto cleanup and anything obvious
Remove unused CSS
Fix HTML

Go through file browser, hitting at least each file type (title page, copyright, chapter, etc.).
If you don't like appearance, figure out what's causing it and change. Have a set of rules, such as non-massive headings (1.4em), less empty space above and below headings and sections (margin: 0.5em 0), left justify, no dropcap or the like, 1.4em indent, 0 left right margins.
Eliminate unwanted files (more praise for). Possibly move intro to end. Edit TOC to conform.

Repeat run check, remove, fix. This time through put more effort into fixing errors.

Focus on nice book appearance rather than clean code. Some of this could probably be scripted.

My process is something like this...

I run Modify ePub until it says there is nothing left to modify. That's 1-3 runs before the next run says nothing needs to be modified.

I check the cover and if the cover is correct and hi-res, it's good to go otherwise, I'll try to download a good hi-res cover from Amazon, Google, Apple, or Kobo. I'll copy the cover and once I open the book in the editor, I'll replace the cover and size it for my screen. I'll check other graphics and see if they need resizing. Once done, I'll give the graphics a lossless recompress of 70.

I edit the OPF to remove any crud and the description unless that is correct meaning no advert junk and it's complete.

Then I'll go though the HTML files and delete the ones I don't want such as list of other books, review blurbs, previews, adverts, etc.

I'll then link the stylesheet to all the HTML files so it's there and correct. If there are any fonts, I'll delete the ones I don't want. If any of them are sans-serif, I'll change the font families to sans-serif. The others can go.

Then I'll remove unused classes and add in my classes that I use. There's not many of them so it's not a problem. I will delete the ones that are duplicate (the original ones in the CSS) and I'll edit any of mine if need be based on the original class.

Then I use diaps editing toolbag to drop the <p class="some repetitive paragraph style"> to just <p> as that will then use my style. I'll also clean up any unused <span> and <div>. I'll also use the tolbag to remove any divs I don't want as in vellum code.

I'll change the titles to <h2> so that again uses my style.

I'll then search for class=" so I see what classes are where. I make any changes needed. I do change the smaller text so it's all 1em unless it's supposed to be larger.

I'll also change any section breaks to what I prefer. When done, I also change em-dash to have no space before or after. I'll also change en-dash to an em-dash. I'll also change an ellipse to have no space before or after. If it's three periods with or without space, I'll change them to an ellipse character.

When I am done, I will run the calibre error checker. Any unused graphics I will delete. Any errors I will fix except for font names as that's not an error.

I'll then run epubcheck and when that comes up with no errors, I'm done.

This sounds like a lot more work then it really is.

[JSWolf]

Originally Posted by foosion

Go through file browser, hitting at least each file type (title page, copyright, chapter, etc.).
If you don't like appearance, figure out what's causing it and change. Have a set of rules, such as non-massive headings (1.4em), less empty space above and below headings and sections (margin: 0.5em 0), left justify, no dropcap or the like, 1.4em indent, 0 left right margins.

I find it's easier to search for class=" because I don't have to actually look at the text to see if I spot anything I want to change. If I know what the class does, I'll either edit it, leave it, change it, or remove it. So this means no scrolling through each HTML file to see what's what. All the ones with <p> mean standard paragraph unless it's proceeded with an <hr/>. It also means that once I've search/replaced all of the section breaks, my search won't stop at any of them.

[Sirtel]

I don't care about pretty code, I only care about how the book looks like on my ereaders. So I do much less than many others here. I don't check before editing, as there is always something I want to change.

After fixing the metadata I open the book in the editor. First, I delete all the unwanted files - ads, samples/excerpts from other books, praise, recommendations and the like. Then I remove unused css, check some of the html files and edit what I don't like. No huge headings, no margins, line-height, unusual font size or any font family in the body text. No spaces between paragraphs. Text indents 1em. Fully justified. Hyphenation disabled. Widows and orphans 1. Nice blockquotes with even left and right margins.

I save my edits and look at the book in the viewer. I also check the TOC and fix/create it if needed. If everything is ok, I'll run the page count plugin. An existing page count means I've edited the book.

I don't bother with any error checking, as most of them are harmless and will be ignored by my ereaders. Only rarely there is something that makes my Kobo choke. I fix those as they happen. As I said, that's rare.

[JSWolf]

Originally Posted by Sirtel

I don't care about pretty code, I only care about how the book looks like on my ereaders. So I do much less than many others here. I don't check before editing, as there is always something I want to change.

After fixing the metadata I open the book in the editor. First, I delete all the unwanted files - ads, samples/excerpts from other books, praise, recommendations and the like. Then I remove unused css, check some of the html files and edit what I don't like. No huge headings, no margins, line-height, unusual font size or any font family in the body text. No spaces between paragraphs. Text indents 1em. Fully justified. Hyphenation disabled. Widows and orphans 1. Nice blockquotes with even left and right margins.

I save my edits and look at the book in the viewer. I also check the TOC and fix/create it if needed. If everything is ok, I'll run the page count plugin. An existing page count means I've edited the book.

I don't bother with any error checking, as most of them are harmless and will be ignored by my ereaders. Only rarely there is something that makes my Kobo choke. I fix those as they happen. As I said, that's rare.

I do check for errors because there could be something I did that needs fixing. It takes hardly any time to check for errors.

[Sirtel]

Originally Posted by JSWolf

I do check for errors because there could be something I did that needs fixing. It takes hardly any time to check for errors.

Well, you also do a lot more with the code than I do. My changes are mostly cosmetical.