This page summarizes the coding conventions and best practices adopted by Zubax for LaTeX documents.
The following repository contains a set of templates that should be used for all documentation published by Zubax: https://github.com/Zubax/document_templates. Usage of any other templates is discouraged.
To use LaTeX and the required dependencies on a Debian-based system (e.g., Ubuntu or Mint), install the following packages:
Visual Studio Code
VSCode is the recommended choice for editing LaTeX documents. Use the following extensions:
Don't forget to configure Hunspell for SpellRight, otherwise spell checking will not work.
Do not force capitalization in headings. For example, "Power supply characteristics" is a well-formed heading, whereas "Power Supply Characteristics" is not.
On the importance of hyphenation
Ensure that LaTeX can hyphenate long words used in the headings, otherwise bad things may happen.
If LaTeX doesn't know how to hyphenate a word, you can help it by typing
\- within the word at the desired hyphenation points; for example,
\- sequence will not be rendered in the final document.
Consider the following listing:
If we were to compile it (e.g.
pdflatex -interaction=nonstopmode test.tex), we'd see the following disaster:
Observe that the page numbers for the entries 1.3, 1.3.2, and 1.3.3 have been pushed off their places. This happened because of two things:
- LaTeX didn't know how to hyphenate the long words at the ends of the respective headings.
- The default tolerance settings didn't permit LaTeX to move the offending words to the next line, because that would have required it to put large white spaces between words on the previous line, which it considers ugly.
We can fix it by providing LaTeX with explicit hyphenation specification for the problem words, e.g.,
It also makes sense to tell LaTeX that it's okay to have long white spaces in the table of contents, because the alternative that we can observe above looks far uglier. In order to permit that, use the macro
\sloppy (it is commented out in the example listing above). This is what we get as the result:
Avoid unnecessary column separating lines! 90% of tables can do just fine without them at all.
Vertical column-separating lines can be useful only if:
- The table contains a lot of columns that should be sensibly grouped. In this case, the vertical lines are used to separate columns that belong to different groups.
- The cells in the table contain a lot of text, so that the separating lines improve the readability of the text.
If nothing of the above describes your situation, you don't need column-separating lines!
When using table footnotes, label them using lowercase letters rather than numbers. This eliminates confusion between regular footnotes (which are normally numbered) and per-table footnotes. The first table footnote should be labeled
a, the second
b, and so on.
The coding conventions for documentation are far less strict than those used for program source code, for obvious reasons of the different levels of complexity and maintenance requirements.
Blocks of code should be indented with 4 spaces. Tab characters should be avoided whenever possible.
No line of code should be longer than 120 characters.
Trailing whitespaces are not allowed; make sure to configure your text editor to automatically trim trailing whitespaces on save in the entire file.
Every text file should contain exactly one empty line at the end.
Allowed end-of-line character sequence is Unix-style (
\n, LF). Windows or Mac line endings are not allowed.
Working with graphics
Avoid inclusion of complex graphics in the EPS format, because it tends to be rendered poorly by pdflatex. Prefer the PDF format instead.
When exporting graphics from Wolfram Mathematica, try PDF first, and if it doesn't work (the PDF export feature often breaks on complex graphics), resort to EPS. Overall the exporting workflow should look like this:
- Export the graphics from Mathematica to PDF (if it doesn't work, use EPS). If annotations or other changes aren't necessary, the process ends here.
- Open the exported file with Inkscape.
- Ungroup the graphics (right click --> ungroup). If the graphics file is a plot that contains grid lines, move them all the way to the back (select the grid lines and press "End" on the keyboard). This is mandatory, otherwise the quality of the exported image may suffer.
- Edit the graphics as necessary (e.g. add annotations), and save it as Inkscape SVG with extension
- Delete the temporary file obtained in the step 1. There is no need to keep temporary files. The Inkscape file, however, should be kept under version control in order to make editing easier later.
- Export the file from Inkscape into PDF and include it into the LaTeX file.
It is best to avoid grid lines when exporting via EPS; or, if they are still required, try to avoid making them dotted or dashed, because these features tend to look ugly when exported through EPS.
Linking to Confluence pages
Whenever you need to refer to a particular Confluence article, avoid copy-pasting its URL from the progress bar, because that link would be non-persistent, meaning that it may break if the article gets renamed or moved. Instead, click
Share in the page menu, and then copy the short URL offered by the website. The short URL is persistent, meaning that it won't break, no matter what happens to the page as long as it is not removed.
Remember that by convention, variables in math expressions are written in italics, which is the default, whereas text is written in normal font.
In order to suppress useless warnings about improperly filled hbox, add the following in the preamble of the document:
Always check the warning outputs of the compiler, especially when compiling the final version of the document!
The following script is an example showing how LaTeX documents can be compiled manually without an IDE. Note that the invoked commands largely depend on what particular distribution of LaTeX is used.