boxplot xticklabel overlapped with xlabel

how do I　deal with the problem that xticklabel is overlapped with xlabel using boxplot when I change the size of xticklabel? my code is shown as follows:

Dat = importdata('compu.txt');
x1 = Dat(:,1);
x2 = Dat(:,2);
x3 = Dat(:,3);
x4 = Dat(:,4);
boxplot([x1,x2,x3,x4],'color','k','Labels',{'HIHB','HILB','LIHB','LILB'});
h = findobj(gca, 'type', 'text');
set(h,'FontSize',25);
set(h,'VerticalAlignment', 'middle');
set(gca,'FontSize',25);
xlabel('Xlabel');
ylabel('ylabel');

After I have executed above code, the xticklabel is overlapped with the xlabel. While "set(h,'VerticalAlignment', 'middle');" would make the xticklabel not overlapped with picture.

I have tried the code like "set(h(1),'position',get(h(1)) - [0 5 0])" to set the position of xticklabel . or like "xlabel('xlabel','position',[pos(2) 1.15*pos(3)])"

they all didn't work.

Anyone can help me?

[dpb]

Re: comment I made earlier below about submittal to TMW as enhancement request--I got to wondering and tried; for regular axes via plot, xlabel does cause a resizing and avoids the overlap so the logic with tick labels and axes labels does properly account for the font size.

What the problem is with boxplot is that the apparent tick labels aren't tick labels at all but other text objects part of the complex group of objects created.

Hence, it really is possible to consider the behavior a bug; the implementation just doesn't consider the extent of the objects correctly.

It is an m-file; looked at the implementation in R2012b to see if there were by any chance an easy fixup. Unfortunately, it is very complex in trying to do the computations required to make stuff fit and the issue comes up with the interaction with xlabel that knows about ticks and tick labels but not about more exotic critters that such as boxplot use. It seems they could've use the 'xticklabel' property and then it would (I think) have been ok, but since didn't xlabel doesn't know to make any corrections. Oh...that raises a question...let's try something--well, pooh! :( that didn't work, either. I thought perhaps if instantiated values for the ticks/tick labels and made them large, maybe then the xlabel would recognize where they were now and be written in the right location respecting them. While they occlude the barplot labels when visible, when clear them again they underlying text is again visible. Unfortunately, though, when doing that the xlabel text wasn't rendered visible and couldn't figure out where it went so that ploy didn't work, either.

"It's a bug..." albeit not likely one to be fixed any time "real soon now" given interaction between the way boxplot is implemented and xlabel.

Answer 1

[dpb]

Raise bottom of axes 'position' property if you insist on such large font sizes. Of course, must reduce height the same amount...

pos=get(gca,'position');  % get current axes position vector
dh=0.1;                   % guess for height adjustment value
pos(2)=pos(2)+dh;pos(4)=pos(4)-dh;  % raise bottom, reduce height
set(gca,'position',pos)   % resize with that modification

Adjust the 0.1 example value to suit.

[desword jacky]

Thank you for your answer! However, it doesn't work and the bottom just raises with xlabel. below is dh=0.1

below is dh=0.4

[dpb]

Huh. I figured the ticks would move with the axis but the legend would stay put. Guess you'll have to mess with the 'Position' property of the xlabel text object too, then. Save its handle when you create it for easy access.

[dpb]

OK, I just used the default example for boxplot and messed around with it...

>> set(findobj(gca,'type','text'),'fontsize',25,'verticalalign','middle')
>> pos=get(gca,'position');
>> dh=0.1;
>> pos(2)=pos(2)+dh;pos(4)=pos(4)-dh;
>> set(gca,'position',pos)
>> hXlb=xlabel('Interference Level');
>> set(hXlb,'fontsize',25,'verticalalign','top')
>> set(hXlb,'position',get(hXlb,'position')+[0 -10 0])
>> set(gca,'fontsize',25)
>>

left me with

which isn't perfect yet, but illustrates it's doable this way. I was hoping that if did the rearrangement of the axes lower edge first, then wrote the xlabel that would be the clue as to where to put it, but it appears the internal logic is based on other logic and isn't smart-enough to handle font sizes over the full range.

NB: the y-offset is in "data" units so the value of 10 I used will be far too large for your data range; try 1.0 or thereabouts initially; you might have more luck in 'normalized' mode in setting a percentage of area if you have differing data ranges to deal with. Looks like using your example would be good submittal to TMW official support at www.mathworks.com as enhancement request/quality of implementation issue.

ADDENDUM The image I attached is, it appears, one step before the final; the larger fonts on the Y-axis don't show; they do on the screen but not worth fixing that up here, doesn't affect the problem at hand.

Well, I subtracted another 10 from the legend y-position and it looks really good on the screen..

but as the above shows, saving it or at least attaching the saved image doesn't show that up...it doesn't look any different here altho it does on the screen... :(

[dpb]

Just as an aside, I looked into the boxplot m-file a little more; the issue with the above result seems to be that rather than a fixed location relative to axes position for a given font size, the annotations are done via a set of callback routines so they're dynamic with the location of the axes; hence the symptom you saw originally. It appears the breakdown is in some of the preparatory computations that create the dynamic position for the text aren't up to the task for the placement with really large fontsize values. Then, of course, legend "knows nothink!" of these non-ticklabel objects in order for it to be able to avoid tromping on their space.

It is, as surmised before, an implementation bug that obviously inhouse testing never uncovered that nobody thought to increase fontsize to a value large enough to expose the issue.

Answer 2

[dpb]

OK, played some more and got the below...

This was created by first creating an axes and setting its xlim/ylim ranges to match that of the coming boxplot with x- ylim, then writing xtick labels and x and y legends as desired. At that point, then

posAx=get(hAx,'position');     % retrieve axis position with adequate spacing
hBox=boxplot(rand(20,4)*2.5);  % a boxplot with data in right magnitude
ylim([0 2.5])                  % make ylim match your figure w/o extra default spacing
delete(findobj(gca,'type','text'))  % wipe out the boxplot labels that are problematic
set(gca,'xtick',1:4,'xticklabel',{'HIHB' 'HILB' 'LIHB' 'LILB'})  % and write the labels wanted
set(gca,'position',posAx)      % reset the known good position for the axes from previous plot
hXlab=xlabel('Interference Level');  % and add the label

Shouldn't have to go through such gyrations, but this seemed to work to get the spacing to again interact properly between tick labels and the legend; I'd've thunk just wiping out the text and resetting the 'xtick', 'xticklabel' properties again would've been enough but it wasn't sufficient by itself; had to do the manual resizing.

"Precomputing" it and writing the labels seems better than the previous heuristic spacing for general use.

The only major difference here is that boxplot sets 'xtick',[] so there are no tick marks on the x-axis but are on y-axis. This can't be simulated with HG1 that I have; the 'TickLength' parameter controls both together, not x- and y-independently. I don't know if that extra granularity has been added with HG2 or not; perhaps with the ruler object it can be done, would guess likely so.