Categories
Evolution

How Whales Change Climate

When whales were at their historic populations, before their numbers were reduced, it seems that whales might have been responsible for removing tens of millions of tonnes of carbon from the atmosphere every year. Whales change the climate. The return of the great whales, if they are allowed to recover, could be seen as a benign form of geo-engineering. It could undo some of the damage we have done, both to the living systems of the sea, and to the atmosphere.

FAIR USE NOTICE: This video may contain copyrighted material. Such material is made available for educational purposes only. This constitutes a ‘fair use’ of any such copyrighted material as provided for in Title 17 U.S.C. section 106A-117 of the US Copyright Law.

[vc_video link=’https://www.youtube.com/watch?v=M18HxXve3CM’] Subscribe to my channel

 

 

Categories
Agile Editing News Philosophy

Did Bilbo Sail to the West?

How to improve the overall quality of a book


Was it
Bilbo who sailed to the West? Reading Philosophy for Heroes: Knowledge, the first in a four-part series on what it means to be a hero, this seems to be the case. On page 5:

Now, while the case could be made that Bilbo underwent a heroic transformation, that he fought evil, that he traveled to the West and might have used a boat at some point, the story sounds much more like Frodo’s story in Lord of the Rings. The author himself is well versed in fantasy literature, and the amount of media related to the subject is anything but sparse. How could such an error happen?

 

Well, first, let me admit that I am that author. I am not sure if this is the right or smart way to discuss my own book, but some self-reflection is a great way to grow. So, let us analyze where I, the author, went astray.

 

My usual judgement on products (in this case, a book) is that they are a mirror of the company behind them. If you have a little bit of background information, reviewing a product can be like an archaeological dig. Philosophy for Heroes: Knowledge is a multi-layered book. First, it is part of a series. When writing the first book, the other three books had to be kept in mind. In addition, especially being the first book, it had to stand on its own despite its dealing with the basics (philosophy and language). You cannot sell a book called “Philosophy for Heroes” and then tell the reader to wait for part 4 to finally read about what heroism means. Second, it contains a variety of components: study questions, ideas summarizing a section, biographies adding a human element to sometimes abstract explanations, and real life examples. Skimming through the book, especially those components seem to be “added features” that—while adding value to the book—could just as well be removed. This points to an evolution of the book. Looking back, this is actually true, it underwent a number of transformations:

 

  1. A single, very large book
  2. A five-part series
  3. Then, a four-part series
  4. Then, a four-part series with the first book required to stand on its own
  5. Finally, a four-part series, the first book standing on its own, and additional components (study questions, ideas, biographies, examples, etc.)


As this evolution played out, the later changes underwent the least amount of review, while certain parts, that were already finished when devising the initial large book, had so many reviews, the time spent on dragging them along was a waste of time. How does one write a book without having such a large variance of quality between its parts?

 

For this, we look at software development. A piece of software faces the same problem, it evolves, some parts are “fresh,” others have been looked at and tested for years. The solution people came up with is called “Agile” (with one variant being “Scrum”). My current project deals with this subject, feel free to check it out here.

 

The best approach to write something—anything—is to make sure that its pieces stand for themselves. The advantage of this approach is to have those pieces complete and ready, and you can publish each to get feedback and build an audience. Looking back, I should have published each section separately. Sure, someone could piece all the sections together and then have a copy of the book for free. But that takes a lot of effort. Even if it is just half an hour of work, you could have easily bought the book for yourself. Also, the final edit of a book surely connects the independent parts to a greater whole.

 

In any case, if I did follow that “Agile” approach, it would have been Frodo, not Bilbo, throwing the ring into the fire and traveling to the West.

 

Lesson learned.

 

Categories
Editing IT LaTeX Productivity

How to Create a Kindle Ebook with LaTeX

The ebook is now available! Head over to Amazon to get a copy. 

Book publishing is easier than ever, and my favorite language to use to create books is LaTeX. The Amazon ebook upload platform (https://kdp.amazon.com) allows users to upload a variety of formats, but not for LaTeX or its product, a PDF. Why is that? The reason is that Kindle ebook viewers are not simple PDF viewers. Kindle takes the text and reformats it in a way so that it is easily readable and provides the customer a repeatable experience across a variety of books. PDFs, on the other hand, are fixed: no matter what viewer you use, page 37 of a particular book always looks the same.

How then can we use LaTeX to get a Kindle ebook published?

Instead of PDFs, the workflow will rely on HTMLs that are converted to MOBI files. The MOBI files can be imported by Kindle. The big advantage of this workflow is that you can use the HTML files to convert into other formats, such as posting on your blog (which typically requires the removal of all the LaTeX code and a reformatting).

But no worries, we will go through the workflow step by step. I first wanted to give you the big picture.

So, how do we create the HTML file? I am a fan of “one-click” solutions. Whatever we do, LaTeX should generate the final HTML file and we should not have to make any manual changes. This requires some work, but in the end, it is worth it!

For my setup, I am using Overleaf. It offers an online editor, a PDF preview, an automatic Git backup, and a LaTeX compiler on one single website. If you are using a different LaTeX website or your own local installation, a different configuration might be necessary.

Converting LaTeX to HTML

To convert LaTeX to HTML, we need a special compiler, TEX4HT. Unfortunately, TEX4HT only works with pdfLaTeX, not with XeLaTeX or LuaLaTeX. So, as an initial preparation of your existing LaTeX code, you might have to make it compatible to pdfLaTeX. If it is already compatible or if you are already working with pdfLaTeX, you can move on to the next paragraph. If not, you will need to: switch to pdfLaTeX in the project settings; add the ifxetex package; and surround XeLaTeX-specific code with a “\ifxetex … \fi” construction. Having this compatibility allows you to generate PDFs with XeLaTeX, and also produce HTMLs with pdfLaTeX when you switch the compiler settings.

TEX4HT itself needs no installation, as it is already part of the Overleaf setup. All you need to do is include it in your workflow. In Overleaf, this is done by adding a file named “latexmkrc” in the main directory of your project and adding a configuration file (you can find an example here).

First, let’s create the latexmkrc file in the main directory of your project:

$pdflatex = “htlatex %S \”my.cfg,MyFonts,NoFonts\” \”\” \”\” -shell-escape > output.txt; pdflatex -synctex=1 %O %S”;

All this does is override the way Overleaf names the compiler $pdflatex, calling it htlatex in addition to pdflatex, and writing the output of the compilation of htlatex to a new file called output.txt. It also references my.cfg, where much of the HTML configuration resides.

When the compilation has finished, the HTML file will not show up within Overleaf. Instead, you have to actually download the output files (use the drop-down menu at the bottom left in the project window). In the downloaded zip archive, you should check the output.txt for errors. If there are no errors, the HTML file should be in the same directory, ready for use! You can unzip the file, open it in a browser, and there is your ebook! On to step two!

Converting HTML to MOBI

The main tool we will be using (besides LaTeX) is the Kindle Previewer. To preview how your HTML will look on various Kindle devices, download the Kindle Previewer here. Besides previewing, it also converts the HTML to MOBI, which can be uploaded to the KDP website or to a Kindle. Generally, for a professional ebook release, it is recommended to get a set of Kindle devices for testing. With the Kindle uploader tool, you can easily send your MOBI files to a specific device.

Now, open the HTML file with the Kindle previewer. It might give you helpful compiler warnings for you to fix, as well as a conversion to MOBI. Once all is in order, you can browse through your ebook with different Kindle device simulators and, finally, upload the MOBI file to KDP.

But wait! It does not look right!

Now we have to go a little deeper. First, you may wish to review the design documentation by Amazon.

During the conversion, we lost page breaks, maybe some lines, spacing formatting, indentation, etc. The bad news is that there is no 1:1 conversion possible. The good news is that we can include our own .css file to correct a few issues and redefine some of the environments in LaTeX itself to make things right. I will talk about this in a later article. Here, I will talk only about a few instances I have encountered. For others, that is up to you, especially if you used custom formatting in your LaTeX document.

For example, the title sizes might need some fixing:

h2 {
    font-size: 1.5em;
    margin-top: 0.83em;
    margin-bottom: 0.83em;
    font-weight: bold;
}

h3 {
    font-size: 1.17em;
    margin-top: 1em;
    margin-bottom: 1em;
    font-weight: bold;
}

h4 {
    margin-top: 1.33em;
    margin-bottom: 1.33em;
    font-weight: bold;
}

h5 {
    font-size: 0.83em;
    margin-top: 1.67em;
    margin-bottom: 1.67em;
    font-weight: bold;
}

And—kind of a hack—if you dislike paragraph indents, this is the way to go for Kindle:

p {
    margin-top: 1em;
    margin-bottom: 1em;
    text-indent: 0.01em;
}

In LaTeX itself, you might also want to redefine some commands. The following will move your footnotes to the end of the ebook (if you don’t, they will be put into external html files which are not included in the ebook), add a new command “myrule” for horizontal lines, a new command “emdash” for em-dashes, fix semi-colons, and rewrite newpage to tell Kindle to insert a page break.

\ifxetex

\else
    \usepackage{endnotes}
    \let\footcite\citep
    \ifx\HCode\undefined 
        \def\myrule{\hrule}
        \newcommand{\emdash}[1][]{\hspace{0pt}---\hspace{0pt}}%

\else
        \def\myrule{\HCode{<hr style="clear: both" />}}
            \def\semicolon{\detokenize{;}}
            \def\emdash{\HCode{&\#8212;}}% 
            \renewcommand\newpage[1][]{\HCode{<mbp:pagebreak />}}
    \fi
    \let\footnote=\endnote
\fi

That is all for now, I will add a second part with more details (like the table of contents, additional design options, and the index) later. But with some luck, I hope you get your ebook working with these instructions! Feel free to ask questions in the comment section.