Continue reading »]]> This post finishes the series of blog posts on LaTeX for your thesis. I will quickly introduce:

• the best LaTeX graphics package I know
• my LaTeX typing environment using vim

TikZ ist kein Zeichenprogramm (TikZ is not a drawing programme)

This is probably the best graphics package available, it feels like you can do anything you like with it and the output looks highly professional. However, it takes a bit time to get used to. The start is very easy, these two lines enable the library and some components which I found useful (you might want to enable those only when you actually need them).

There are multiple layers of its use, you can start drawing simple lines, but higher-level parts provide support for graphs, mind maps, bezier curves etc. Here is a simple example for an illustrated finite-state machine:

As you can see, lines are terminated by a semicolon, so you can whitespace-format your code to make it well-readable. The resulting image is a vector graphic (whereas my screenshot of it isn’t…):

Of course this is only a small fraction of what you can do. In fact the package is so versatile that people actually made a website full of TikZ-Examples (including pictures of the results). The complete guide can be found in the official manual, which is well-illustrated using TikZ itself. The name PGF relates to the lower layer of the package.

Editing with vim-latex

If – and only if – you are a fan of and proficient in vim anyway, I recommend the LaTeX-Suite for vim (a.k.a. Vim-LaTeX). One of the biggest benefits is obviously that you can still do things like ct, (replace the text until the next comma) while editing LaTeX. However there are many more things added specifically for LaTeX editing.

A very useful combination is autocompletion together with jump markers. E.g. if you type matrix and then press <F5>, vim-latex replaces that with

where your cursor is placed in the middle of the matrix environment. Now you can put in the desired content and then press Ctrl+j to move the cursor directly to the marker <++> (which is then removed). This works also for eqnarray, tabular etc. Not needing to type all those curly braces is very relieving. This also works for smaller commands, e.g. `2 is replaced by \sqrt{}<++> and `/ is replaced by \frac{}{<++>}<++> (cursor between the first pair of braces in each case). Needless to say that you can also add your own templates.

Furthermore you can compile and show the pdf file directly from vim using (in command mode) \ll and \lv respectively. Folding and syntax highlighting go without saying. Here are some of the definitions I use in my ~/vim/ftplugin/tex/texrc to further speed up typing:

It is also a good idea to use vim’s spelling support (independent of vim-latex) for your thesis. Just put

into your ~/.vimrc and enable it only for your thesis using a so-called mode line. This is done by making the following line the last in your .tex file:

You can then add good and bad spellings into the spellfile using the :spellgood and :spellwrong commands.

For now this concludes my blog series about LaTeX for your thesis. Please tell me if I have missed important tips or packages or you would like to contribute a guest article.

Continue reading »]]> Quoting in standard LaTeX has got a few drawbacks:

• Depending on which language-packages you use, you sometimes need "', sometimes just " for quotes (otherwise it might print umlauts).
• Switching between the type of quotation marks late means you have to replace them throughout your document.
• You have to pay attention to using different quotation marks when nesting them.
• Literal quotes are not directly associated to the reference you give. And you cannot easily search for them in your document (\cite also appears independently of quotes, quotation marks also appear for other reasons):
  "'To be or not to be"'\cite{hamlet}

The package to solve all of your quotation problems is called csquotes.

In case you don’t know, the babel package provides basic internationalisation support, e.g. for splitting words at the correct positions.The csquotes package’s autostyle option depends on the babel package for recognising your document language. It then sets the type of quotation marks according to the mapping given in the options.

Here is a small usage example:

The first line introduces the \enquote command, which basically just places the text in the appropriate quotation marks. However, for the nested quote, the marks are automatically switched to double quotes. The \textcquote command associates a quote with a citation and behaves mostly like manual quoting with an added \cite. The output looks like this:

Since csquotes has got many more options than these, you might want to refer to the manual.

Continue reading »]]> This is a follow-up post of this one

Consistency and speed are two major issues in writing your thesis. First, you want important and particularly technical terms to appear typeset in a consistent manner throughout the whole thesis. Everything else would just look unprofessional, and given that you chose LaTeX you seem to be serious about that point. Secondly, these kinds of names tend to be quite long and also appear frequently. So instead of typing your fingers bloody, you should make use of Latex being essentially a programming language and define variables, a.k.a. aliases or new commands. This is usually done using \newcommand. You can do that anywhere in the document, but I would recommend grouping all aliases together in the preamble. Let’s look at an example (sorry for the logic domain, but this is where all my current LaTeX texts are set in …):

The output looks like this:

So what is going on? The first two examples do not have any parameters, but show that aliasing works both in text and math mode. Normally, these aliases bring up problems with spaces directly after them. You always need to have a space to delimit the command use from the normal text following it, so usually Latex does not print this space. This would lead to the first example ending like this:
The \xspace command provided by equally named package “just does the right thing”, so no trailing space in the first case, but in the second one. The next two examples show how to use parameters. The number in brackets gives the number of parameters, and you can subsequently access them with #index. This is useful e.g. when you don’t want to fix the notation yet (as in the power set example), or when building shortcuts for complex operators.

This is pretty much all that is important about aliases in LaTeX, xspace mostly works out of the box, so for once no need to RTFM.

More LaTeX tips for your thesis are coming up soon. If you have any wishes of packages I should write about (or even a guest article), please tell me about it. So long, happy writing…

Continue reading »]]> As many of my fellow students, I recently entered my last term at Imperial College. In contrast to the previous terms, there will not be any lectures, instead everyone will focus on some development or research, and on writing a report / Master’s thesis about it. Since this is my second thesis already, I got to know quite a lot of useful Latex packages and will share some tips in this the follow-up posts.

FiXme – Annotate your PDF with ToDos
When you are in writing mode, you usually just want to do that – write. Especially as opposed to working on administrative stuff like fetching and including the right BibTex data or looking for a specific quote, or reading into how to format that image. Still, you need to do those things later and don’t want to forget coming back to them. Instead of having a separate list of such ToDos, you can insert them directly into your LaTeX code at the right position and render it in the margin of the pdf, using the FiXme package:

The margin comment looks like this:

This might also come in handy to point your reviewers to parts you are especially concerned about. For more information on useful options, e.g. different escalation levels (note, warning, error) or displaying FiXme’s as footnotes, see the FiXme manual

More tips to follow soon…

Continue reading »]]> A while ago, I was contacted by a user who only accidentially found out about the git plugin I wrote for Dolphin almost a year ago. He pointed out that Google, the magic gate to the internet, did not immediately provide a conclusive answer about the existance of this plugin and how to activate it. This post is about to fix that problem.

So, what to expect from a git plugin for Dolphin? Dolphin is the well-known file manager for KDE and can be used to manage all the files and folder on your computer. If you are a programmer, some of these folders will probably be checkouts of a version control system, such as git or Subversion. There are several actions to interact with these systems, such as adding new files to the repository, making commits or checking out specific versions. The usual way to trigger these actions is via the command line. For convenience, Dolphin offers the most frequently used ones in its context menu, so far for SVN and git. Furthermore, the version control states of the files, such as “added to the repository” or “modified since the last commit”, are indicated for each file with icon overlays.

Enabling the git plugin
To enable this functionality, you first need to install the plugins. They are part of KDESDK, here are some package names for common distributions:

• (K)Ubuntu: kdesdk-dolphin-plugins
• openSUSE: dolphin-plugins
• Arch Linux: extra/kdesdk-dolphin-plugins
• Gentoo: kde-base/dolphin-plugins

Now, you can enable the plugins in the dolphin settings:

After you restart Dolphin, you should see both icon overlays and the new context menu entries whenever you enter a folder that is managed by git.

[Update]Notice that remote access (push / pull) currently only works for authenticated remote repositories and users, i.e. your SSH key must have access to the repository and you should have confirmed the public SSH key of the remote repository on the console before. Password-based login is also not possible at this time.[/Update]

This post is mainly about the git plugin, but there are also other version control systems. The very first plugin to be supported was Subversion (svn), introduced in KDE 4.4. As part of this year’s Google Summer of Code, Vishesh Yadav implemented a plugin for Mercurial, which will be part of KDE 4.8. I also spotted a Bazaar plugin in the KDESDK trunk. So, if you are into programming, be sure to check out the next version of KDE!