automatic plot labels about matlab2tikz HOT 13 CLOSED

As long as it's common to place the figure caption below the figure I can't see an easy fix for this. Implementing this in matlab2tikz implies that \label{} is placed inside the *.tikz-file. However, since \label{} must be placed after \caption{} to get the reference correct, this can only be achieved if the figure caption is placed above the figure (or \caption{} is called before \input{}) - which is quite unusual (as far as I know).

from matlab2tikz.

There's a difference between the label for the figure (as in "figure 1") and the label for the plot lines (as in "dotted with triangular marks"). I think the user refers to the latter.
It wouldn't be any problem at all to add \label{something-something} after each addplot(), I just haven't done it yet. Not really sure if it's useful at all since one would have to open the file and check what the labels are called anyways before one can \ref{} them in the caption or wherever, and once the file is opened you could easily insert your own label anyways. The purpose I can see is to educate people about the possibility of labeling lines.

from matlab2tikz.

That's true - I had completely forgot about that possibility. Maybe it could be an idea to give the possibility to do automatic labeling if a flag for this option is provided in the function call, e.g. matlab2tikz('filename.tikz',.....,'labelPlots',true), which would add \label{filename-pn} after each plot.

I agree on that if the order of the data in the *.tikz-file isn't known, there's little to gain by providing this, but if the order is known, one can refer to the different plots without having to open the file at all.

from matlab2tikz.

Yep, maybe by issuing something on the command line. I'll think about it.

from matlab2tikz.

Been thinking of this, but just want to check if you maybe see any problem with my solution which I miss.

Thought that we can add

% add label to non-empty environments if command options set to true
if m2t.cmdOpts.Results.labelPlots && ~isempty(strfind(env,'addplot'))
    env = [env, sprintf('\\label{plot:%s-p%d}\n\n',m2t.tikzFileName(1:end-5),n)];
end

in the handleAllChildren() function, at the very end right before the line pgfEnvironments{n} = env;, and

m2t.cmdOpts = m2t.cmdOpts.addParamValue( m2t.cmdOpts, 'labelPlots', false, @islogical );

in getEnvironment().

However, I have a feeling there's something more I should check but I can't say I know what. Any input?

from matlab2tikz.

Well, first of all it's not environments that are labeled, but plots (I think of environment as something that starts with \begin{...}, like semilogxaxis or tikzpicture).
I like the idea of putting it in handleAllChildren() though because then we don't have to scatter this code all over m2t. What's difficult is how to determine when to put a label. Most of them will be \addplot, but there's a bunch of other ones too. -- Think of \addplot3, for example.

from matlab2tikz.

Yes, I agree on the environments part, but as the code is today, all the plots are stored in the env variable in the handleAllChildren() function, even though the content of the variable may be code for a plot.

As of now, both \addplot[] and \addplot3[] will be catched by the if-statement as the pattern 'addplot' is present in both. But for others plots I think it's just to expand the test to something like

if m2t.cmdOpts.Results.labelPlots && ...
                sum(cellfun(@isempty,arrayfun(@(l)strfind(env,labels{l}),1:length(labels),'uni',0)))>0

and define a cell labels (or whatever) with all the different plots that should get a label if the command line options for this is set to true (or something equivalent).

Also, the plots that should be labeled will also be controlled by the plots that are supported by matlab2tikz. E.g. if matlab2tikz didn't support \addplot3 it wouldn't be any need to add 'addplot3'.

from matlab2tikz.

addplot3 will indeed be caught by just parsing for addplot, but this is really unclear code and I can see someone such as myself trying to mess around with this in a few weeks when I've forgotten about this.
That sum() condition is epic. What is that doing?
You're right that we should add labels only for supported plots, so I'm thinking right now may it would be better to add something like

if (addLabels)
    % add label bla
end

at the end of every function that makes sense to have label (such as drawLine() and a handful of others). What do you think?

from matlab2tikz.

arrayfun() is just another way of looping through data. However, since the output from arrayfun() in this case will be cell with entries that are either empty or non-empty, isempty() will not work properly, e.g. it will return 1 no matter what the entries in the cell are (empty of not). Thus, using cellfun() will allow one to use isempty() on cell inputs and check which of the cell entries that are empty (returned value is a logic vector). Now, since we only need one of these cell entries to be non-empty, I used sum() in the example above - e.g. if the sum is greater than 0 this means that at least one entry is non-empty. But this can be done in many other ways - e.g. you can always use a regular for loop to make it more understandable, or replace the sum() with any() - which will return 1 as long as any of the inputs are greater than zero.

e.g.

for k = 1:length(supportedPlotTypes)
    if ~isempty(strfind(env,supportedPlotTypes{k})
        supportedPlotType= true;
        break;
     end
end

if (addLabels && supportedPlotType)
    bla bla
end

As for your suggestion, adding this inside all the functions that make the plots you lose the possibility to have the numbering of the plots (unless you add some counter to the m2t struct which is checked and increased in each of the functions that add the labels). But I have to say that I haven't checked all possible plots for the numbering with the code above either - so in the end it might be that adding some counter to m2t (or some field of it) will be the best solution.

from matlab2tikz.

Been testing some more with this, and it seems like the counter for the number of plots with labels has to be stored in the m2t struct some where in order to get this to work properly. E.g. with something ala

[X,Y] = meshgrid(-2:.2:2,-2:.2:3);
Z = X.*exp(-X.^2-Y.^2);
[C,h] = contour(X,Y,Z);
colormap cool

hold on;

plot(0:pi/20:2*pi,sin(0:pi/20:2*pi))

the contour plot consists of 12 plot lines whereas the sine-function is a single plot line. However, since they are treated as two different plots the counter will start over at 1, giving two or more equal labels unless it's placed somewhere in the m2t struct.

Also, plots with text nodes give rise to a problem as the env variable in handleAllChildren() will become a cell-array when these are processed - resulting in that env = [env sprintf(.....)] will cause an error. However, text is the only case I've experienced so far that results in this, so adding an if-statement checking if env is a cell or not solves this. Thus, something ala

      if m2t.cmdOpts.Results.addLabels && ~isempty(strfind(env,'addplot')) && ~iscell(env)
          if ~isfield(m2t,'labelNum')
              m2t.labelNum = 1;
          else
              m2t.labelNum = m2t.labelNum+1;
          end
          env = [env, sprintf('\\label{plot:%s-p%d}\n\n',m2t.tikzFileName(1:end-5),m2t.labelNum)];
      end

works just fine.

from matlab2tikz.

So one thing I've been thinking about is that putting the label in the file directly would only make sense if we also print the label on the command line and clearly associate it with the user's plot.
Otherwise, what the user will have to do is open the file, go the the specific plot he wants to refer to, and check out what the label is. If he or she has to do that, there would hardly be any gain over putting the label there yourself in the first place.

from matlab2tikz.

That's a good idea which is very easy to fix.

from matlab2tikz.

Fixed in commit 549083e.
This works for lines and surfs now, and can be added for other plots if deemed appropriate.
All in all, I'm not very happy with this as it adds (slight) complication to the code and provides only a tiny bit of improvement. Oh well; the users will decide whether or not this thing is useful.

from matlab2tikz.