BaFigExPro (v. 2.7)

The BaFigExPro package provides an automatic method to export Matlab figures, with optional uniform styling. Several input/output folders can be given in a single call. The routine works both for Windows and Linux (tested on Matlab 6.5 and 7.x).

- export figures to eps and optionally pdf, jpeg, png and tiff files. By using the eps file as an intermediate file for the other format, the typical huge white blank frame around the figures that Matlab adds when exporting in other formats is not present. The routine can also be used to export with any Matlab print format.

(v. 2.5)
*fig files having dots in their name are allowed
*latex interpreter restored if lost at saving
*'activeposition' and 'marginfactor' options added as resizing parameters
*'stylemap': behaviour slightly modified to allow unique Matlab style
*undock figures before formatting if necessary

(v. 2.5.1)
*bug corrected in latex interpreter restoration

(v. 2.6)
*improved automatic margin adaptation to avoid label or outsided legend clipping when resizing figure with axes in 'position' mode ('adaptaxes' option).
*'tight' option to obtain the smallest possible margins.
*'marginfactor' option extended to allow absolute control on margins. In 6.x versions, it now helps the automatic axes adaptation.
*'eps_loose' option added to gain control on exported figure width.
*'customcode' option added to include custom code execution at different locations within the formatting process.
*'paperunits' option added.
*'locklimits' option added.
*'dsubset' option added to select subset of folders. 'fsubset' option now limited to files.
*fig2public can now be called without any parameter
*Help headers rewritten

(v. 2.7)
*default figure styles have been externalized and extended (see presetformat.m). Several options have been added to the 'base_config' parameter. To keep the old defaults, add 'old' to your 'base_config' input.
*option 'lockaxesaa' has been added to increase robustness of 'tight' margin mode.
*a few input parameter verifications have been added to help the user.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
History:

The package is based on eps2xxx by Primoz Cermelj (slightly modified) and exportfig by Ben Hinkle (greatly modified). After a thorough testing of exportfig, I saw that it was not working fine for many cases that I was needing (e.g. figures with large labels for presentations). So, I nearly rewrote it and added some cool stuff.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Usage:

Unzip the package and call fig2public. Read the help headers of the different routines! The version log is also useful... In general,

1) generate and store fig files in a folder (be minimalist in terms of format processing, always use command line calls to perform them).

2) call fig2public with the source folder and the output folder as arguments. Add all the options that you need. Many are available. The options of the different subroutines can be given directly to fig2public.

3) enjoy the output. Use the tex files in the output folders to copy-paste inclusion code.

the fonts are unfortunately waaay to small. It works ok for the "painters" renderer, but I cant use this one due to FaceAlpha and light.
Apparently the fontsize is only correct in the png, when not defining eps_res.
But I have to set it to 800 to get a decent resolution..
Maybe someone knows what to do?
Regards,
Johannes

Thanks Jon. yes Lube is my real name. When I get around to processing whichever line plots were causing issues I'll get back to you. Oh wait, I just remembered! If you try plotting a line through some data points so that the point markers are shown as well (i.e. '.-'), then the way the dots are scaled means they are hidden behind the lines. Hence the need to scale the markers manually.

There's also another issue that I was thinking of where the dots from a dotted line (i.e. ':') don't come out square but as rectangles, but i think this is an issue with the eps conversion (i.e. not your fault!).

I also just discovered an issue with the 'painters' eps renderer for surface plots, which is that black lines overlaying the plots seem to get randomly converted to other colours. Probably best to use the openGL renderer for surface plots (you might want to update the header options in fig2public to include opengl.). For the benefit of others I found this article helpful in understanding the difference between the renderers: http://www.mathworks.co.uk/support/tech-notes/1200/1201.html#Section_2

Option names
Ok, I see your point now. It's just the help header that is wrong. Use the correct parameter names (as in the parameter structure line 469) to overcome this. I'll update a corrected version when time allows.

Dot scaling:
When dealing with ':' lines, the size parameters are 'linemode', 'linewidth', 'linemin' and 'linemax'. I've done a test and it seems to work correctly ('-' and ':' lines are scaled identically). Send me an example if you still think there is a problem here.

Hi Jonathan,
Thanks for getting back on this. Appreciate that you are busy.
Option names: compare lines 253 with 469 and 470 of formatfig.m, and the same for lines and markers. As it is the string comparison obviously fails. Trivial yet important!
Dot scaling: I was referring to the former i.e. ':'. The dots are incorrectly scaled. I think this is the same problem as discussed here: https://sites.google.com/site/oliverwoodford/software/export_fig.
When you get a minute please have a go at working out these bugs as this really is the best software package out there for preparing figs for papers!
Thanks for all your work.
Cheers.

Yep, I am still around, but I don't have much time at the moment. Concerning the last comments:

tiff in black and white:
- I've never tested it, it must be in the gs conversion from eps to tiff. You should check what eps2xxx does. It can be avoided, if really necessary, by avoiding the eps altogether (see the help header of fig2public).

latex interpreter:
- yep, I tried to go around the bug in Matlab as best as I could. It works for simple expressions. For the rest, I guess you have to play around with your figures manually.

simple example:
- there are examples in the help header of fig2public. Please read them before commenting...

Zi-An Li:
Thanks for the comment! I leave the corresponding rating to my general incapacity to understand things.

Option names:
I don't see why.

'dot' scaling:
I am not sure to understand your point. Which kind of lines are you speaking of? A pure line (i.e. ':') or a mixture of marker and line (e.g. '.-'). According to your comment, I have the feeling that you're speaking of the 2nd situation. In that case, it's not a bug. It's just that lines and markers are two different things. You therefore have to set the options for both types individually.

Another Bug:
the options for fontsize and markersize in formatfig should be specified as:
'fontmin', 'fontmax' etc. as opposed to 'fontsizemin' and 'fontsizemax'.
Also default behaviour for a 'dotted line' plot causes the dots to be scaled smaller than the lines. Can't figure out why, use 'markermode','scaled','markersize',2 as a work-around.
It seems the author is no longer supporting this, which is a shame as this is an excellent package...
If anyone knows how to get in touch with him, then please do so!
Cheers.

Digging a little deeper it turns out this is actually a bug with Matlab to do with the way it draws/resizes figures. I think it is treating the latex-interpreted x-label text box as a Tex-interpreted text box, which has a much smaller vertical extent. See e.g. page 5 here:
http://automatica.dei.unipd.it/tl_files/utenti/varagnolo/matlab/HowToMakePrettyFiguresWithMatlab.pdf
Also here: http://www.mathworks.com/matlabcentral/answers/2621-figure-title-labels-in-latex-cutoff
You can see what is going on if you do set(get(gca,'Xlabel'),'EdgeColor',[0 0 0]) after creating the x-label. In tex format you see the whole box, but in latex the bottom is cut off.

The best workaround I found for this was to place the following code after creating the x-axis label:
set(gca,'Position',get(gca,'Position')+[0 0.01 0 0])
this simply shifts the entire figure up by 1% of the height of the 'OuterPosition' box (explained here: http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html)

Sorry for these lengthy posts. I hope they help someone. Author feel free to edit them down. Cheers.

When using the Latex interpreter for the axes labels the (x-axis) label is, depending on the figure height or axis proportions, very slightly cropped by the bottom edge of the figure. I think what is happening is formatfig is ignoring the interpreter, working out the figure size etc. based on standard text, then re-setting the interpreter at the end. It seems the latex labels are slightly taller than the standard matlab labels and are therefore being cut off. I think this is what the author is referring to in his comment in line 1015 of formatfig.

As a workaround I first used the following piece of custom code, which I set to be executed at the end via the 'bot' option:
customcodestr = [...
'xlabh = get(gca,''XLabel'');',...
'set(xlabh,''Position'',get(xlabh,''Position'') + [0 1 0]);'];

This simply gets the handle of the x-axis label, then using this gets the position, then shifts the vertical position up by 1 y-axis unit.

I then found a simpler workaround:
customcodestr = ['set(get(gca,''XLabel''),''VerticalAlignment'',''middle'')'];
Fortunately the vertical alignment was set to 'Cap' therefore 'middle' bumps it up a bit and 'bottom' by quite a lot.

I then used this in the following command which takes a figure produced using semilogx with completely default format options, and exports it to all formats:

Both of these did the trick in my case where the problematic label was '$f$ [Hz]'.

A better option might be to have the routine check the position relative to 'OuterPosition' and then move it relative to the axis height or distance between the y-coords of 'Position' and 'OuterPosition'. The problem is these axis properties are given in normalised units and not data units like the label.

I haven't yet managed to find a solution to the colour tiff problem yet, and it looks like the author is away?

Thanks for this. Really excellent. However when I go to resize a figure and within the figure's directory I enter e.g. fig2public('height',9,'width', 12,'other_formats',{'pdf','tiff'});
the figs in the directory are resized and exported in colour for all the formats except the tiff, which comes out in black and white. Am I missing something?
Cheers.

Thanks for the feedback. Standard options go back to the very first version and should probably be revisited. When I have time, I'll try to find an elegant solution. The best choice of options depends on the kind of figures (multiple axes, log-scales, etc), the figure usage (reports, articles, presentations, etc) and personal tastes (that's a very long list here...). What I usually do is that I put all the most common options in a structure and I call fig2public on different subsets of figures, giving the common option structure as input and redefining the options particular to a set of figures within the calls themselves. By the way, using the 'tight' option is meaningful only if you also use 'eps_loose', otherwise the exported figures should already be quite tight (but the exact figure dimensions not controlled).

I like it! Use of the standard options didn't produce something legible, but when I used the second tier suggestions (locktick=true, 'tight', 'x' and linemode=fixed, linewidth=1) I got a beautiful set of figures...thanks for all your hard work!

All the formatting is done via the function formatfig.m. All its options are reachable directly in the call to fig2public. So, you get the option that you need with:
>>help formatfig
Then you use the 'param_name',param_value input (ie in addition to your other options) to set its value, for example:
>>fig2public( ..., 'linemode','fixed','linewidth',2, ... )

How can I explicitly set the parameters such as - "font size, marker size, line width, color and figure dimensions" and not use the default options set for an "article" or "slides" at the execution of the fig2public command ?

Thanks.

Updates

24 Mar 2009

The main feature of this update is the compatibility with Matlab 7.x and simple TeX inclusion code generation. For the rest, read below and check the changelog file. Comments and feedback welcome.

Many new options with a special focus on automatic figure margin correction to avoid label or legend clipping. Exportation of figures with tight margins and absolute dimension control is now possible. For the rest, see the description section.

16 Dec 2010

Handling of default figure styles improved and extended. For the rest, see the description section.