Tools & Processes used
Both editions of “Embedded Software for the IoT” are published via CreateSpace on Amazon. I chose this solution mainly because it intrigued me. The fun in doing it all myself!
The second edition is not completely true to this concept, as I had help with proofreading from my daughter Amanda. Additionally, a good colleague – Camilla Travis – helped with the cover.
The following is a list of tools used in the process, for those interested.
Word-Processing. On Amazon there are a lot of books on writing books for CreateSpace. They are all, as far as I know, based on Word. I use Word a lot in my day-job. Maybe for this reason, I was not too happy about using Word. It simply isn’t good enough. I knew about Latex, and when I saw something written by a good colleague, Jens Hee, I decided to try it out. I have not looked back since. Well, maybe when I was creating the e-book – see further down.
I implemented a number of enhancements in the second edition, such as improved micro-kerning. This makes the text even prettier. I am sure that I have benefited from being a programmer. Not that I have programmed anything in Latex, but the entire concept feels good when you are used to programming and compiling.
To be precise, I used pdflatex, with MikTex for editing.
Diagrams. In the first edition, I used MS Visio for diagrams. It has a good collection of elements that you can piece together, but it lacked a number of features. For the second edition, I switched to CorelDraw. I loved Corel in the old days, but believed it was dead. It wasn’t. It’s not straight-forward to use, but neither is Visio.
In the first edition, all graphics were exported as PNG-files. This was OK for screen-shots, but a big mistake for vector-graphics. I should have known better, but got fooled by looking at PDF on-screen. The PDF-viewer by default shows things differently than they are printed. Always test on print!
Naturally, I did print the whole lot several times, but when I got to that point I had fooled myself to think that it could not look better.
In the second edition, vector-graphics (from Visio and Corel) are exported as PDF into Latex, which in reality passes it “as is” to the printer. Much better.
Excel graphs are also exported as PDF. A hidden gem in Excel.
Getting PDF-graphics right on the printer is a challenge – see my blog-post on Raster-Image-Processing: RIP.
Process-wise I would like CorelDraw to have a batch-mode export (see below on backup).
Graphs. The sines, spectra etc. in the DSP-chapter are generated in Maple. This is a nice program – but very expensive. Personally, I prefer the “1D” input-mode where the input is textual, much like Latex. The graphs in the SPC-chapter are generated in Excel.
Screen-Shots. I have simply used Microsoft’s Snipping Tool for this and exported as PNG’s in both editions. For the second edition I re-did many of these to make them more readable. Mostly this was done by focusing on only parts of the screen, or by increasing font-size. The latter was done with all WireShark images. In the first edition I ran all screen-shots through Gimp, to make them look better in Black & White. It became clear that this added no real value, and the concept was dropped in the second edition.
Backup. For backup I used “git”. It is one of many tools described in the book, so it made sense to take my own medicine. See e.g. Table of Contents.
I saved versions on a daily basis. This works great with Latex text, but when using graphics there is no compression. I need to save the CDR-files from CorelDraw. This takes a lot of space.
When the git repo is pulled to another PC to work from here, it is cumbersome to go through all CDR-files manually, exporting them to PDF, so I also saved PDF’s whenever I thought I was “done” – which was often not correct. Thus the repo grew fast. This would not be so extreme if CorelDraw supported a batch-mode export, allowing me to treat CDR as source and PDF as compiled output.
When I worked on the first edition I did not use git, but a simple backup script that saved all content to a Google Drive (described in the book as “poor mans backup”). This was easier to work with, from a backup point-of-view, but using git allowed me to look at “diff’s” and to retrace my footsteps – just like working with code.
Calibre. This tool is used together with “kindlegen” as a two-step process to get from the html to the kindle “mobi” format.
Wireshark. In a way this is just one of many tools demonstrated throughout the book. However, no other single tool appears on so many screenshots. I owe Gerald Combs, founder of Wireshark, a huge THANK YOU for allowing me to use Wireshark screenshots in the book. Wireshark is the tool to use when capturing & analyzing Ethernet traffic.
E-books are very popular for fiction-books. They handle the many different screen formats by letting text flow freely. The user may select font-type and size, and may even tilt the device for a new layout. Obviously, this makes it difficult to control a text full of tables and figures. This means that e-books are challenging for the non-fiction writer.
Basically, it should be simple to use the same Latex-source that was used for pdf, to generate html – but it isn’t. Many constructs are legal in pdflatex, but not in the htlatex. Math formulas are not treated well either. They are converted to special graphics known by most web-servers – but not by e-books.
This is relevant because html is a stepping-stone towards e-books. I did the necessary changes for the first edition – it can be done. When the html is in place, it is run through a tool called “Calibre”. This generates a “standard” e-book. Now this is run through “kindlegen” to create the final format used on kindle.
I imagine that life is a little easier if Word is used here 🙂