Matlab2Tikz

Today’s post begins with some background ranting. If you want to skip it, feel free.

For quite a while, I’ve been thinking about moving my plotting a bit further away from Matlab. And why is that? Well, let’s just say that the Matlab plotting utilities have some…issues. Or not the plotting itself; that actually works quite fine indeed.

It’s the exporting that always gets me. It works okay-ish if you export your plots as bitmaps, in which case you either end up with a gigantic file, or with poop-smear quality. Export them as pdf or eps, and you are screwed. Whatever you do, something tends to break down. When a new Matlab version comes out, things that previously did work begin breaking down in a spectacular new fashion.

For example, there are the bounding box issues. Namely, any pdf-export is surrounded by lots and lots of white space. That can usually be fixed with a few (~10) lines of extra code, but these workarounds often work for typical figure aspect ratios only. Trying to export a figure of a slot (or anything else really thin) breaks it down, and I still haven’t figured out how to fix that. Additionally, dotted lines have been broken since eternity, and been exported as some sort of perverted cross-slashed lines instead.

However, the last straw for this camel were the fonts. Mainly, Matlab uses the system fonts for figures by default. Exporting the figure then as a pdf (or eps for that matter) retains this information. Now, when you use this figure in your LaTeX-publication, this font – being owned by Microsoft if you are using a windows computer – is not embedded in the resulting pdf. This, in turn causes the IEEE pdf checker to have a fit and yell about missing fonts like it’s the end of the world.

Which is an awesome thing to notice two hours before the conference deadline.

Which causes me to have fit and yell about anything, in a totally unsuitable-for-print fashion.

In the end, I did the only reasonable thing there was to do and thoroughly violated my paper with poop-smear bitmaps. The resulting file was barely under the 4 MB limit set by the conference organizers.

I still can’t sleep properly because of that.

Aaaaanyway, this finally brings us to today’s actual topic: making Tikz figures with Matlab, without suffering excruciating pain in the process. For those even less familiar than me, Tikz is basically a package for making plots (and also flowcharts) in LaTeX, using very tex-like commands. Accordingly, matlab2tikz is a free Matlab script that some immensely helpful soul made for exporting plots as plain Tikz script. In the simplest form, the script outputs a piece of code, that you can then copy-paste or input into your main document file.

Obviously, this is not always a good idea. Tikz-scribing a complex plot can result in quite a huge number of commands, which then take long to compile into a pdf (or ps or dvi or whatever you heretics may be using). Furthermore, many journals require separate pdf files of each figure in your paper, so you are gonna need those anyway. Finally, I’m grown fond of figures in pdf-format for no reason in particular, and would hate to input lots of separate tex-files into a big one.

So, to solve all this issues, I put together a tex-file and a function for Matlab. The first one, when compiled, gives out a (hopefully) nicely-cropped pdf figure, corresponding to the file Tikz formatting file texfig.tex. This file, in turn, will have been generated in Matlab by the function file I just linked here. Additionally, this same function will also take care the compilation process.

This function takes as inputs the figure handle (e.g. gcf) and axis handle (e.g. gca) pointing to the figure to be exported. The strings dir_Tikz and name_tex correspond to the path and name of the tex-file described earlier; and the former also corresponds to the location of the temporary files that will be generated during the compilation. The dir_Miktex corresponds to the location of my Miktex Portable distribution. Obviously, if you have an actually installed version, you can replace with [] and simply call xelates as such.

The Matlab function also tries to set the legend position in the final pdf to correspond to the original Matlab figure. Right now, only the lower-left corners of the legend boxes will match each other; the rest may differ depending on the box sizes between Matlab and the pdf. Also, the axis font sizes are set to approximately correspond to the typical IEEE article recommendation.

The compilation step – in effect – calls the Windows command line, setting the current directory to the desired one and then calling the LaTeX compiler of your choice (XeLatex, obviously) in the “-quiet” mode, i.e. without any command window output. The resulting pdf is then copied to the desired directory and renamed.

The files have been tested on a couple of simple plots only for now, so don’t be shocked if they don’t work as expected after all. Nevertheless, I’m going to keep you updated about me experience with them, and any improvements I come up with along the way.

I’m also working on externalizing some of my most computation-expensive tasks from Matlab to pre-compiled executables. Tentatively, I’m thinking of using the Eigen library to make a bunch of dll’s for easy coupling, but let’s see what happens. Going to start with some basis matrix generation for a particular frequency-domain MoR approach, we shall see, we shall see indeed…

Matlab2Tikz