Forum: Author Hangout

Ernest, are you using a single HTML file for your entire book, or one per chapter?

A single file.

I write the stories in using the Libre Office word processing program. Then I save a copy as html, run a script to clean out all of the excess coding, run another to replace the usual html codes for the character format codes and paragraph codes to convert them to what I want to use in the stylesheet code, followed by opening that html file in a text editor to paste in a copy of the css code into the file. That way I have one large file for Calibre to convert to e-pub and it then splits at the h1 and h2 tags as it makes the table of contents and the creates the epub file.

Part of the file bloat is due to Calibre including its own stylesheet code for anything I didn't cover as a span command. So in the early versions where I used the < b > and < i > commands Calibre created it's own span commands and included extra code in the sylesheet for each chapter where those usual html commands appeared. Thus there would be a span command for bold1 in chapter 1 then another for bold 2 in chapter 2 etc. By having them in the file I created the span commands ended up in the stylesheet as only 1 entry, thus saving space.

Playing with the files in the last few days is how I found out I needed the character commands at the head of the css code in the file instead of the bottom of the css code.

Tonight I also found out that creating a table to include listed items results in a tighter e-pub file than using an ordered list or an unordered list, and I don't know why that is. However, I had one book with a lot of lists in it, and when I converted them to tables to improve the way they displayed the new e-pub file was half the size of the old one using lists.

Why include the style code in the html file and not keep it as a separate css file?

I have one big file with all of the chapters in it, so having the stylesheet code in the html file or in a separate file makes little difference. By having it in the actual file it means the I need only copy the one file to have it all there. Also, there are a few books with a bit of extra style code and that code is only in the files for the relevant book.

Does Calibre split the single file into multiple files and/or split of the css into a separate file before converting it to an epub?

I'm not sure when or how it does it, all I know is I input a single file and I get a single e-pub. However, when I use Calibre to edit the file it shows an internal html file for every h1 and h2 chapter in the story with the various overhead files for the epub. This makes me think the epub file is some sort of zip style file.

I'm more interested in converting epubs into html

I thought an epub was HTML.

Does it extract the css too and put into a separate file?

yes.

People say Word (so I assume LibreOffice as well) generates bloated HTML

Yes it does.

Have you ever tried inputting a LibreOffice file into Calibre rather than generating HTML from LibreOffice and then inputting that HTML output into Calibre?

Yes, and it doesn't give the same appearance as the method I use, as well as resulting in the creation of a huge css file with a full set of code for each chapter. It does the same thing with .docx and every other text file with built in formatting.

Have you ever tried inputting a LibreOffice file into Calibre

Back when I started creating e-pubs I had one document which had a lot of lists in it to display the data in a specific way. It also had a lot of underlines, subscript, and superscript. This was before I developed the css code in the html file. I created the file direct from odt to e-pub and the finished file was 2.7 MB for just under 9,000 words. I recently added text to make the file 9,700 words, created the html file with css code for underline, superscript, subscript, and the latest css code in the file. When I created a new e-pub from the new html file the finished e-pub file shrunk from 2.7 MB to 0.2 MB - however you look at the results, that's a hell of a drop in file size. It more than justifies, in my mind, the little work I go through to make the html file to create the e-pub.

I'll admit that over the last few years I've spent a lot of time and effort in learning how the css code works and playing with it, but it was worth the effort learn it because the current system only takes a few minutes to go from odt to the e-pub while also providing good html files to lodge with SoL and for my personal use.

ayep, that's about the best description of what I do.

Back when I started creating e-pubs I had one document which had a lot of lists in it to display the data in a specific way.

I gave up on list elements a while back, as it's easier to code them yourself, they look better, and they don't leave those annoying blank lines after each list item. In html, you simply add "& bull;" (no space) at the start of your indented line. It's a tiny bit of extra work, but it looks neater and is more consistent. And, if you mix it with hanging indents, you get very neat list items neatly tucked into each other.

I gave up on list elements a while back,

I had only the one book with lists in it, but I was shocked when new file with tables was 0.2 MB while the original file was 2.7 MB. But the original e-pub wasn't done with my css code while this one was. Thus I suspect a lot of the reduction was due to just using the css code. I do like the way the tables improve the look in the finished product over the way the lists looked.

The table list issue was with the Basic Math Notes book which had a lot of them due to the subject matter.

yes Power Tool uses lists of the people and the commands.

that one is not on SOL

It's not on SoL as it's not a story. If anyone wants a copy of the relevant code I'm happy to send it to them if they send me a Private Message so we can exchange emails to send attachments.

The epub version I made back in April was befo9re I created the latest very fine tuned css code set. Also, the last few years the epubs of the Clan Amir series have been a single large anthology of the whole series with it being split up for SoL. So I've not got comparable stats for you. Also, due to my current legal issues I won't be working on the series until June 2021.

You can control list item spacing with CSS, you know.

You can, which I've done, but it's difficult to eliminate the trailing space after the final < /ul> command. For me, it's easier simply avoiding the cumbersome automated list structure entirely, as the results look cleaner without it.

But, that's my personal opinion, and I'm sure that most will disagree with it. For most, using lists is a no-brainer, regardless of how it looks.

You can, which I've done, but it's difficult to eliminate the trailing space after the final < /ul> command.

No, it's not.

ul { margin-bottom: 0; }

Yeah, that makes sense, I'm guessing I'd customized the le commands but not the ol, despite making other changes to it.

There must be some other reason why your books are generating multiple CSS files.

CW,

there's only one css file in the epub, but Calibre adds lots of extra code with css items names of things like Calibre 1, Calibre 2 etc. Having everything in the css code I submit, and putting the in-line format code first reduces those added css code items. When I examine and older file (yes I still have one) where I didn't have the everything in the code the stylesheet created by Calibre has an entry in the css for each splie that's exactly the same but with a name which indicates each one is for a specific split.

The old file has a css of 434 lines for a 4 chapter story of under 1,000 words and is 0.7 MB while that story is included in a new document of 42,500 words for 0.4 MB with a css of 165 lines covering 56 chapters.

So something is being changed by the inclusion of the css code and the order it's laid out in.

there's only one css file in the epub, but Calibre adds lots of extra code with css items names of things like Calibre 1, Calibre 2 etc. Having everything in the css code I submit, and putting the in-line format code first reduces those added css code items. When I examine and older file (yes I still have one) where I didn't have the everything in the code the stylesheet created by Calibre has an entry in the css for each splie that's exactly the same but with a name which indicates each one is for a specific split.

Those various Calibre settings are formally duplicates, ensuring that your code confirms to Calibre's dictates. Whenever I specify various details in my H1 commands, Calibre puts in Center1 and Center2 settings which definitely duplicate or modify my own settings.

However, I don't get ANY duplications associate with my in-line code, just the 'override' settings to prevent users from narrowing the margins and other settings too much.

Just a quick correction: ol = ordered list, ul = unordered list. You can set an attribute type="x" on an ol element where x = A, a, I, or i. For a numbered ordered list you can set an attribute start="x" where x is the number to start the list with.
Examples: < ol type="a"> ..., < ol start="50"> ...

Thanks! I'd completely forgotten about that option, as I'll often expand one list element over more than a single line (by referencing the previous names of my revised books), but they keep throwing off the numbering in my book list. Now I have a handy way of working around that situation, but will definitely need to redefine my ordered and unordered lists to prevent duplicate blank lines following them.

In my case, I basically started my own lists after changing them to 'hanging indents', where multiple paragraph indents all line up under the initial & bull; flag. You get much more control with the hand-coded ones, particularly as the indents vary depending on the width of the numbered lists.

@Ernest:
Those extra style definitions mostly serve to restrict what you're allowed to do in Calibre, as my centered H1 chapter headers contain several versions of my simple "centered" command, duplicating my < span clause>, but the duplications are only made once in the single CSS document, so other than complicating my H1 chapter headers, they aren't really providing much processing overhead.

CW,

I'm not sure what you're doing different to me, or what I'm doing different to you, but I've noticed a major change is file size due to the changes, and checks shows most of it comes down to the in-line formatting.

In the older files where I had no css and used the html commands of < b > < / b > < / i > within text paragraphs Calibre was converting them to span commands and inserting specification in the stylesheet with the same info repeated with different numbers, one for each split for each type of paragraph or text variant in each split. Thus one small file ended up with 44 definitions with the great majority of them being the same few repeated but with a different number for the split it's in.

That 1,500 word file is now included within a 42,500 word file done with the new css code in it which includes 4 extra font type formats plus two extra font size formats as well as in-line font color commands above what was in the old file. Yet the new and larger version has a total of 24 definitions in the stylesheet and none are repeated.

In some documents I had the in-line code for bold, italics, blue, red, and green at the bottom of the css code list in the originating html document. But when I changed those to being and the top the finished file size reduced some more, despite the only change being to move that section of code from the bottom of the list to the top of the list for that html document.

Old file of 1,500 words is 0.7 MB, new file with 42,500 words plus extra colours and character formats is 0.4 MB. As I said before, I don't know what the reduction happens, all I can report on is the empirical evidence that I see happening.

Since this thread started I went through and recreated all the recent e-pubs with the new code order, and that's the only change I made to the code was to shift the in0line code to the start of the css code, and every single e-pub I've done that to has had a reduction in size.

I should really update the writer guide with that change in code order.

Also, while I think about it. If you add a cover image in the metadata section where you can select and image file to include, you should not include the code to insert a copy of the image within the book itself, as that will result in two copies of the image being included in the file.

I'm not sure what you're doing different to me, or what I'm doing different to you, but I've noticed a major change is file size due to the changes, and checks shows most of it comes down to the in-line formatting.

In the older files where I had no css and used the html commands of < b > < / b > < / i > within text paragraphs Calibre was converting them to span commands and inserting specification in the stylesheet with the same info repeated with different numbers, one for each split for each type of paragraph or text variant in each split.

You may have identified the discrepancy. I've long used my own CSS (or at least Style Definitions), I've NEVER witnessed my in-line formatting being converted into html span commands! That might because I've also never used "italics" or "emphasis" commands, relying on the simpler < I> and < b> commands.

Also, while I think about it. If you add a cover image in the metadata section where you can select and image file to include, you should not include the code to insert a copy of the image within the book itself, as that will result in two copies of the image being included in the file.

Unfortunately, Calibre doesn't give you an option of including the cover image in your file. However, it's easy enough to either delete the entry entirely (stripped the cover image from you book list profiles so they display correctly within Calibre), OR replacing the image with a standard Title Page.

But as I intimated earlier, I suspect that since I make such extensive use of graphic images, I'm not detecting the smaller character level differences you're observing.

Unfortunately, Calibre doesn't give you an option of including the cover image in your file. However, it's easy enough to either delete the entry entirely (stripped the cover image from you book list profiles so they display correctly within Calibre), OR replacing the image with a standard Title Page.

You can change how to handle covers within Calibre you can go to Preferences - Common Options - Structure detection - there's an option 'Remove first image' if you wish to tick the box to active it.

Another is Preferences - Output Options - EPUB output - there are options 'No default cover' and 'No SVG cover' if you wish to tick the box to active either of them.

Also, when you use the menu option 'Edit metadata' there's options there to include or change the cover image.

For those who input DOCX files will like that in Preferences - Input Options - DOCX input - there is an option 'Do not try to autodetect a cover from images in the document' so if you wish to tick the box to deactive it looking for a cover within the document.

Another aspect is if I include the standard < img src = " " > commands within the text of the html file I'm using as the input file a copy of the image called ends up in the file immediately after the Cover Image selected in the Edit metadate option.

.........................

I just did some experimenting and having the usual img src command to insert an image within html in the input file will definitely include the stated image in the file at the point it is in the text. When I have the img src command immediately after the < body ... > command and before the story title information and use the Output option of No Cover with No svg cover the epub opens with the image, but the edit option shows there is no cover image within the epub package.

I suggest you check out and play with the various options to find a set of options you like.

typo edit