InDesign epub code cleanup

[nabsltd]

Originally Posted by paperwhite13

This is also something I don’t understand yet, sorry Especially the 'why bother restricting' part. Do you mean you could reuse the class for the other headings?

h2.chapterheader {} only applies to the h2 element. If you decide that you need to move levels up or down in the heading structure (i.e., h1 becomes h2 or h2 becomes h1), you need to go back and change the stylesheet, becauset the old h2.chapterheader {} won't apply to an h1.

On the other hand, if your stylesheet only referenced .chapterheader {}, then it doesn't matter if that class name is in an h1, an h2 or even a p, it will still get applied.

Why not use the bare (L.E.: styled) h1 for the normal chapter, and h1.specialchapter for the rest? Why is there a need for a h1.normalchapter?

h1.specialchapter has to "undo" everything that the bare h1 declares if it doesn't match what you want h1.specialchapter to look like. You either do this by making h1.specialchapter declare all properties or by just declaring what needs to change.

In the first case, you aren't using the base h1 at all in h1.specialchapter, so why pretend it's related to the base? In the second case, if you change the base h1, then h1.specialchapter will also change, if you didn't override that property. If that's not what you want, you have to change both declarations.

My way means I only change the declaration I want to change, and don't have to worry about any other side effects. Part of the reason I do this is because physical books often had what would be h1 and h2 in an EPUB having formatting that has nothing at all in common. For example h1 was a fairly large sans-serif font centered (the chapter number) with a very large bottom margin, while h2 was left-justified, italic, and only slightly larger than the body text, and a normal bottom margin ("datelines" that occured 3-4 times per chapter).

[nabsltd]

Originally Posted by JSWolf

Is this KFX or KF8? Does it work on Kindles other then the Scribe or PW5? What does it look like without the line-height in CSS?

Without the line-height property, KF8 and EPUB (both Sigil and Calibre preview) leave a very large gap (nearly a full line). KFX, on the other hand, only increases the line height by a couple of pixels. It's visible, but not terrible. Once again, KFX is better at "doing the right thing, even if it's not exactly what the code said to do" compared to KF8.

I have no idea what it looks like on devices I don't own.

[Quoth]

On physical epub readers with user line-height, like a Kobo, it's fixed if it's set in the ebook. If there is no setting, then the user can change it easily from no spacing to more than double spaced. The font metrics set larger relative spacing for larger fonts.
Also you see the absolute space is different on different fonts of the same size.
There is less control on a Kindle, but none if the line-height is set.
I forget what the iRiver, Sony, Nook etc do.
Different Andriod apps behave differently.
KOReader can override CSS like line-height. Many apps won't.

I don't like naked tags. I think it's less error prone that at least <p> and <hx> have classes in the CSS.
This is a good point:

On the other hand, if your stylesheet only referenced .chapterheader {}, then it doesn't matter if that class name is in an h1, an h2 or even a p, it will still get applied.

You want to be able to change the tag (semantics if you like) without unexpectedly changing the visual rendering.

[JSWolf]

Originally Posted by nabsltd

h2.chapterheader {} only applies to the h2 element. If you decide that you need to move levels up or down in the heading structure (i.e., h1 becomes h2 or h2 becomes h1), you need to go back and change the stylesheet, becauset the old h2.chapterheader {} won't apply to an h1.

On the other hand, if your stylesheet only referenced .chapterheader {}, then it doesn't matter if that class name is in an h1, an h2 or even a p, it will still get applied.

I agree. That;s why I dislike things like p.center and h2.chapterheader. I see no reason to to it that way. I prefer classes that can be used anywhere you want.

h1.specialchapter has to "undo" everything that the bare h1 declares if it doesn't match what you want h1.specialchapter to look like. You either do this by making h1.specialchapter declare all properties or by just declaring what needs to change.

In the first case, you aren't using the base h1 at all in h1.specialchapter, so why pretend it's related to the base? In the second case, if you change the base h1, then h1.specialchapter will also change, if you didn't override that property. If that's not what you want, you have to change both declarations.

My way means I only change the declaration I want to change, and don't have to worry about any other side effects. Part of the reason I do this is because physical books often had what would be h1 and h2 in an EPUB having formatting that has nothing at all in common. For example h1 was a fairly large sans-serif font centered (the chapter number) with a very large bottom margin, while h2 was left-justified, italic, and only slightly larger than the body text, and a normal bottom margin ("datelines" that occured 3-4 times per chapter).

I disagree. I prefer <h2>Chapter 01</h2>. In most cases, that's all I need. And if not, I don't mind doing what need to be done in CSS to get the class to work.

[JSWolf]

Originally Posted by nabsltd

Without the line-height property, KF8 and EPUB (both Sigil and Calibre preview) leave a very large gap (nearly a full line). KFX, on the other hand, only increases the line height by a couple of pixels. It's visible, but not terrible. Once again, KFX is better at "doing the right thing, even if it's not exactly what the code said to do" compared to KF8.

I have no idea what it looks like on devices I don't own.

Given that it is visible, it's noticed and yes, it's terrible.

[JSWolf]

Originally Posted by Quoth

On physical epub readers with user line-height, like a Kobo, it's fixed if it's set in the ebook. If there is no setting, then the user can change it easily from no spacing to more than double spaced. The font metrics set larger relative spacing for larger fonts.
Also you see the absolute space is different on different fonts of the same size.
There is less control on a Kindle, but none if the line-height is set.
I forget what the iRiver, Sony, Nook etc do.
Different Andriod apps behave differently.
KOReader can override CSS like line-height. Many apps won't.

I don't like naked tags. I think it's less error prone that at least <p> and <hx> have classes in the CSS.
This is a good point:

You want to be able to change the tag (semantics if you like) without unexpectedly changing the visual rendering.

Any Reader that has RMSDK will allow a line height such that the first line will not be off. Sony & nook use RMSDK. I would expect any Reader where the software used that allows a line height to be used should work.

[paperwhite13]

Originally Posted by nabsltd

h2.chapterheader {} only applies to the h2 element. If you decide that you need to move levels up or down in the heading structure (i.e., h1 becomes h2 or h2 becomes h1), you need to go back and change the stylesheet, becauset the old h2.chapterheader {} won't apply to an h1.

On the other hand, if your stylesheet only referenced .chapterheader {}, then it doesn't matter if that class name is in an h1, an h2 or even a p, it will still get applied.

Thank you, I now understand what you meant about moving levels and restrictions, but it doesn’t appply to my InDesign workflow. With an epub exported from ID, it’s not a work in progress, the hierarchy is set, the multi-level ToC is ready and nothing will ever move up or down. At this point it’s just cleaning up.

Originally Posted by nabsltd

h1.specialchapter has to "undo" everything that the bare h1 declares if it doesn't match what you want h1.specialchapter to look like. You either do this by making h1.specialchapter declare all properties or by just declaring what needs to change.

In the first case, you aren't using the base h1 at all in h1.specialchapter, so why pretend it's related to the base? In the second case, if you change the base h1, then h1.specialchapter will also change, if you didn't override that property. If that's not what you want, you have to change both declarations.

My way means I only change the declaration I want to change, and don't have to worry about any other side effects. Part of the reason I do this is because physical books often had what would be h1 and h2 in an EPUB having formatting that has nothing at all in common. For example h1 was a fairly large sans-serif font centered (the chapter number) with a very large bottom margin, while h2 was left-justified, italic, and only slightly larger than the body text, and a normal bottom margin ("datelines" that occured 3-4 times per chapter).

With the h1.specialchapter, I override the few properties that change, and like I said, it’s not really a work in progress, h1 is already set. I understand your concern about side effects, but InDesign *Based On* styles work the same way (if anything changes in the base style that hasn’t been overwritten, the change will propagate), so I'm used to working with a base style for body or title text.

It does makes sense not to style h1, h2 etc. and focus on their semantic roles (which would be akin to the no-style, [Basic Paragraph] in InDesign), so I may end up not styling them in practice, but that means I will end up with declarations for .regularchapter and .exception, the latter of which might be longer than if I had used styled bare tags, am I correct (if I wanted, say, a sans-serif font for both)? It would also make no difference if they were attached to h1 or not, since I wouldn’t be able to use them elsewhere and they would make the style sheet a little harder to follow (it’s easier for me to parse h1.exception than .exception).

[JSWolf]

Originally Posted by paperwhite13

With the h1.specialchapter, I override the few properties that change, and like I said, it’s not really a work in progress, h1 is already set. I understand your concern about side effects, but InDesign *Based On* styles work the same way (if anything changes in the base style that hasn’t been overwritten, the change will propagate), so I'm used to working with a base style for body or title text.

It does makes sense not to style h1, h2 etc. and focus on their semantic roles (which would be akin to the no-style, [Basic Paragraph] in InDesign), so I may end up not styling them in practice, but that means I will end up with declarations for .regularchapter and .exception, the latter of which might be longer than if I had used styled bare tags, am I correct (if I wanted, say, a sans-serif font for both)? It would also make no difference if they were attached to h1 or not, since I wouldn’t be able to use them elsewhere and they would make the style sheet a little harder to follow (it’s easier for me to parse h1.exception than .exception).

It's better to use a naked <h1> if that's going to be be used that way most of the time. Say you have 10 chapters and only 1 has a subtitle. Style <h1> how it will be for the 9 chapters and leave it naked. Otherwise, you have code bloat. <p> is even worse as you'll have severe code bloat with <p class="codebloat">.

The rule is to keep it simple and <p class="codebloat"> and <h1 class="idontneedaclasshere"> is not keeping it simple.

[nabsltd]

Originally Posted by JSWolf

Given that it is visible, it's noticed and yes, it's terrible.

I did not post a screenshot of my test when not using line-height on KFX. How can you say it's noticed and terrible?

With line-height, KFX makes the line space smaller than default. This is likely caused by an error on my part with picking the right number for the line-height.

Without line-height, KFX adds about 1 pixel of extra line height per extra em of the initial capital. So, a 4em capital adds about 3 pixels. This is not very noticeable.

Without line-height, KF8 adds about 1 line of extra line height per extra em of the initial capital. This is insanely ugly.

Again, KFX for the win.

[nabsltd]

Originally Posted by JSWolf

Otherwise, you have code bloat. <p> is even worse as you'll have severe code bloat with <p class="codebloat">.

This is not a problem.

In my library, a 188,000 word EPUB with <p class="para-indent"> is 829,165 bytes. In that EPUB, there are 6,207 p elements with that classname. Changing it to just <p> shrinks the EPUB to 824,776 bytes, a miniscule savings of 4,389 bytes, or less than 1 byte per paragraph.

To put it another way, on a device with 32GB of storage, the you could hold 38,593 "bloated" books, but only 205 more if you remove the "bloat". The use of a meaningful class name far outweighs the space savings.

And, it doesn't really matter how long the class name is. Changing to <p class="ThisIsFarTooLongAClassNameToType"> increases the overall size to 833,321. This is an increase of less than 1 byte per paragraph, and it's a ridiculously long class name that would never be used for real.

OTOH, removing the cover saves 336,714 bytes. That's a lot more "bloat" than anything caused by the HTML and CSS markup.

[Quoth]

Originally Posted by nabsltd

This is not a problem.

To put it another way, on a device with 32GB of storage, the you could hold 38,593 "bloated" books, but only 205 more if you remove the "bloat". The use of a meaningful class name far outweighs the space savings.

And, it doesn't really matter how long the class name is.

I mentioned this to Jon before. An epub is a zip file.
https://en.wikipedia.org/wiki/ZIP_(f...ession_methods
You can rename a whatever.epub to .zip and unzip it with your desired archive tool. If you are a only having a plain text editor and an archive tool you could even make an epub, though knowing structure of the system text files rather than just the HTML and CSS content is a challenge.

So 10,000 instances of a really long class name really is little more than one instance.
Jon: Zip uses LZW and/or deflate
Original LZW replaces matching arbitrary length data with a 12 bit code (one and a half bytes). https://en.wikipedia.org/wiki/Lempel...%E2%80%93Welch

Deflate
https://en.wikipedia.org/wiki/Deflate
Is more computation to compress and uses some similar ideas.

There is never bloat. Having it human readable for maintaining or fixing bugs in automatic epub generation is important.

[Quoth]

Originally Posted by nabsltd

OTOH, removing the cover saves 336,714 bytes. That's a lot more "bloat" than anything caused by the HTML and CSS markup.

Then there are non-alphabetic fonts needed by some languages. A problem if not on the ereader. Bigger than covers.

Illustrated / picture books.

Designers adding big fonts and not subsetting (some non-asian ones won't).

Class names are not an issue.

[JSWolf]

Originally Posted by nabsltd

I did not post a screenshot of my test when not using line-height on KFX. How can you say it's noticed and terrible?

I;m going by what you said. You said it;s noticeable. If it is noticeable, I'll notice it and it will not look good.

With line-height, KFX makes the line space smaller than default. This is likely caused by an error on my part with picking the right number for the line-height.

Without line-height, KFX adds about 1 pixel of extra line height per extra em of the initial capital. So, a 4em capital adds about 3 pixels. This is not very noticeable.

Without line-height, KF8 adds about 1 line of extra line height per extra em of the initial capital. This is insanely ugly.

Again, KFX for the win.

If you can find working code for KF8 where the first line with a large first letter does not cause the first line to be off, post it and i'll try it on my PW3.

Of course, the simple solution is to edit the KF8 eBook and remove the code for the large letter as it's not needed and the book can easily do without it.

[JSWolf]

Originally Posted by nabsltd

This is not a problem.

In my library, a 188,000 word EPUB with <p class="para-indent"> is 829,165 bytes. In that EPUB, there are 6,207 p elements with that classname. Changing it to just <p> shrinks the EPUB to 824,776 bytes, a miniscule savings of 4,389 bytes, or less than 1 byte per paragraph.

To put it another way, on a device with 32GB of storage, the you could hold 38,593 "bloated" books, but only 205 more if you remove the "bloat". The use of a meaningful class name far outweighs the space savings.

And, it doesn't really matter how long the class name is. Changing to <p class="ThisIsFarTooLongAClassNameToType"> increases the overall size to 833,321. This is an increase of less than 1 byte per paragraph, and it's a ridiculously long class name that would never be used for real.

OTOH, removing the cover saves 336,714 bytes. That's a lot more "bloat" than anything caused by the HTML and CSS markup.

One reason for having naked tags is because they look better when editing eBooks. Also, when looking through the code to see what's going on, I don't have to look at a naked tag. So all those <p class="deleteme"> can be just <p> and it's a lot easier to see code that does something different.

[paperwhite13]

Dear people, I understand you have some axes to grind about what is and what isn’t "code bloat" and I hope it gets settled , but at this point all the KF8 and KFX talk has very little to do with the topic? I'm really grateful for the replies I've gotten so far, but I see no use in going through the same points over and over again.