Is it possible to apply CSS to Sigil generated TOC?

[carogray]

We use CSS counters to number questions and chapters in our Advocacy Guides.

We update the guides every year and sometimes insert a question or a new chapter or reorder these.

The TOC consists of Chapters and an entry for each question, but because it is generated automatically it does not capture the numbering of the headings. So the entries we need are all there, but not numbered.

Using CSS to automatically number both makes it much easier to update the guides every year and maintain all the links and internal cross references.

We can use CSS to automatically number an HTML TOC, but wonder if I can apply CSS to the navpoint tags within the automatically generated TOC?

If so, how?

Thanks,
Caroline

[DiapDealer]

CSS counters aren't supported by ePub 2 (which is what Sigil is limited to).

The data in the navpoint tags of an ncx file are usually displayed however the reading system sees fit.

[carogray]

Oh drat - well at least we now know what to do when we eventually evolve to EPub 3, eh?
Solves a bunch of questions for this round.
thanks,
Back to manual numbering
c

[JSWolf]

Originally Posted by carogray

Oh drat - well at least we now know what to do when we eventually evolve to EPub 3, eh?
Solves a bunch of questions for this round.
thanks,
Back to manual numbering
c

Eventually is not going to be any time soon. There are not many devices out there that support ePub 3. Plus, there are a lot of ePub capable readers that will never be updated to handle ePub 3. So don't wait for ePub 3. You'll be waiting a very long time to release your book.

[exaltedwombat]

Originally Posted by carogray

We use CSS counters to number questions and chapters in our Advocacy Guides.

Not in an epub you don't. Sorry.

[Tex2002ans]

Originally Posted by exaltedwombat

Not in an epub you don't. Sorry.

Depends on what programs the readers are ultimately going to be using to read.

If this was a business environment and you knew that everyone was going to be non-ADE readers (iBooks, Readium, ...), or knowing that they were using the newest Kindles only, you can use fancy things like CSS Counters.

If you are selling it through B&N/Amazon/other stores (that are not under your direct control)... then yes... you would not be able to do a lot in EPUB.

Maximum compatibility, sadly means that hard-coding the numbers is your best bet.

In some cases (dropcaps, smallcaps, ...), you can use more complex CSS in your EPUBs, BUT, you always have to keep in mind graceful degradation.

[exaltedwombat]

If you know what reading device will be used, why complicate matters by using an epub format at all? Epub is about pouring text into different sized containers, but necessarily forgoing a lot of control over layout. If you KNOW the screen size and resolution, compose in any program with the features you require, distribute a pdf.

[DiapDealer]

Originally Posted by exaltedwombat

Epub is about pouring text into different sized containers, but necessarily forgoing a lot of control over layout.

Repeating this over and over does not make it true. While it has some merit with regard to reflowable electronic text in general, there is no underlying "precept" of the ePub spec that requires the relinquishing of all (or even most) control over layout. If there were such a precept, there'd be no reason for ePub to support CSS at all. It would just render vanilla if no user preferences were specified. Not a terrible idea by any means, just not very real-world relevant. Is it possible you're confusing what ePub is with what you'd prefer it be?

[exaltedwombat]

Maybe :-) But isn't the reality that although we have some control over styling, we have little over layout?

[DiapDealer]

All depends on where you want to draw the line that defines the two. The point is: ePub's not just a text-pour. If it were, you'd simply define paragraphs, headers and other "archetypal" book entities and let fly. Epub and user settings would do the rest. That may be what you do (and there may even be many advantages to that), but by no means, does it have anything to do what ePub is or isn't. That (the "pouring of text and nothing more" analogy) is a personal, reflowable electronic-text philosophy that you wish others to embrace. Which is fine and dandy as long as you don't present it as anything other than such.

[exaltedwombat]

Originally Posted by DiapDealer

you'd simply define paragraphs, headers and other "archetypal" book entities and let fly.

Perfectly described! Assuming "epub" means "electronically publish" this is very much what a sensible author accepts.

If you're producing personal works of art for your own consumption only, that's something else. But, as I said, if the medium is known and fixed, what's the point of working within the constraints of epub? There are better ways of completely controlling layout and appearance in that case.

[DiapDealer]

Originally Posted by exaltedwombat

Perfectly described! Assuming "epub" means "electronically publish" this is very much what a sensible author accepts.

Were we discussing what a sensible author accepts? I thought we were discussing what the epub format was ABOUT.

If you're producing personal works of art for your own consumption only, that's something else. But, as I said, if the medium is known and fixed, what's the point of working within the constraints of epub? There are better ways of completely controlling layout and appearance in that case.

If you're pretending there can be no middle ground between "pour the text" and "fixed layout" with regard to the epub format, then you're either being very naive or being very disingenuous. It's not simply "Pour or PDF." Stop pretending it is.

[exaltedwombat]

Well, any format's ABOUT what it's useful for, what it's good at! The same way a spreadsheet is about number-crunching, despite its superficial suitability for displaying tabular data - then you need to print a page out and realise why you'd have been better off starting in Word.

I fear there's less middle ground than we'd like there to be, if our e-publishing is aimed outward, not confined to a closed system.

[DiapDealer]

We're obviously done here.

[Tex2002ans]

Originally Posted by exaltedwombat

But, as I said, if the medium is known and fixed, what's the point of working within the constraints of epub? There are better ways of completely controlling layout and appearance in that case.

Or you know that the devices being used to read will AT LEAST have X or Y capabilities (Readium or iBooks means that you can now create an EPUB that has more complex layouts, uses MathML, uses javascript, has some EPUB3 functionality, pop-up footnotes, etc. etc.)

MathML would be an extremely important requirement for many books. In the case of a complex math book, you can say something along the lines of: "This EPUB can only be read on any program that supports MathML". Sure, the amount of readers using programs that read MathML means that your potential market is much smaller, but the possibilities of creating this currently using EPUB2 are close to nil (could potentially be produced with a massive amount of SVGs). (much smaller >>> nil)

With PDF, you will be forced back into the "page" layout. Although you will have more of the advantages of having fixed-format (MUCH more complex looking books, more advanced typography, etc. etc.).

EPUB has the advantage of working on any screen size (plus reflowability, changing fonts, changing colors, changing font-size, changing margins, etc. etc.), while creating a PDF for a specific device means, you will be limited to that "paper size"/resolution.

If you have any examples of reflowable PDFs which work well on small/large devices alike, please share... Also, if you have any EPUB2 examples of math books, please point them in my direction, I would LOVE to take them apart.

I would love to see great examples, and any explanations of workflows of how you got from A to B.

Side Note: Perhaps this company already has a large catalog of already built content (such as the original poster). The way the workflow is set up, they already have a massive amount of code that uses CSS to generate their numbered lists. It is up to the company to weigh the pros/cons of how much time/effort/money it would take to convert to EPUB2 (hard code numbers), or releasing it as is as EPUB2/3 geared towards programs which can handle more complex CSS (and severely limiting the potential market).

Another Side Note: Perhaps these books/documents are not going for sale at all, and perhaps are just there for convenience to users. For example: Here is the 2013 Guidelines as .doc, .odt, .epub, .mobi, .kf8, .pdf, .html, ...

Edit: I just thought of this potential solution. Since you already have well marked HTML, but are only missing the auto-generated #s. Would it be possible to have Sigil carry you most of the way? You can have Sigil auto-generate a toc.ncx, you can then come up with some sort of script to manually add in numbers to each navpoint. Code samples of everything could potentially help us iron out problems (a typical chapter, your HTML TOC, your CSS, the toc.ncx, ...)!