To try and solve this problem, I started looking into writing a plugin for flot to do what I needed. It looked surprisingly straight-forward, but I have run into a minor snag. I First used the draw hook to draw my axis (note: I'm aware this code needs some error checking to make sure the origin isn't off the chart)
function draw(plot, ctx) {
var offset = plot.getPlotOffset();
var origin = plot.pointOffset({ x: 0, y: 0 });
ctx.moveTo(offset.left, origin.top);
ctx.lineTo(plot.width() + offset.left, origin.top);
ctx.stroke();
ctx.moveTo(origin.left, offset.top);
ctx.lineTo(origin.left, plot.height() + offset.top);
ctx.stroke();
}
And this works, with 2 small snags. The first and most important is that for some reason it makes the very last point of my data series change color! See here:
The point in the upper right-hand corner has turned black. By stepping through the code I can observe that this only happens when the axes are drawn. Before my draw code is called, the point is the correct color. So I think it has something to do with the drawing on the first "stroke". For some reason it seems to then apply the black color to the last point. Any idea on how to fix this?
The second problem is that this code is called only after flot has draw everything else (including the data points) which means that my lines appear on top of points instead of underneath them. This is only a problem for those two points that are very close to the vertical axis. Looking at the flot documentation, it mentions a drawBackground hook, but this doesn't seem to actually exist. I tried using it and it complained the drawBackground was null. So what happened? And is there a better place to hook into and draw my axes? I want to draw after flot has worked out the size of the plot area and before it draws the first series of data points.
What's currently on the website API documentation does not match the newest released version (0.7). In order to use the backgroundDraw hook, you'll need a newer version of flot, directly from their github repository. The newest version is fine, but anything after this commit would be workable.
Related
When I create a figure with MATLAB with a title, then use the File|Print option to print the figure, the title is clipped. Please try this code for an example
t = linspace(0,2*pi,1000);
s = sin(t);
figure
plot(t,s)
titleString = sprintf('Multi\nLine\nTitle');
title(titleString)
disp('Now press File|Print Preview on the figure and observe that the title is clipped.')
disp('This happens with all titles, the multi line title makes it more obvious.')
disp('I know I can fix it with Fill Page or Center, but I should not have too.')
You can also see the problem in print preview. As I say in the example code, I know I can get round the problem using Print Preview then Fill Page or Center, but I don't want people using my code to have to use a work around.
I have observed this problem with r2014a and r2015b. I assume other releasse are also affected.
Is there setting I can make before creating the figure that centres the plot or fills the page and makes the problem go away? Is there some other setting I should make to avoid the problem?
Here is a little more debug information. If I press File|Print Preview, MATLAB reports Left 0.64, Top -0.59, Width 20.32, Height 15.24. I guess the problem is related to the negative Top value. These are defaults from MATLAB; I have not made any attempt to change these values.
One extra thing. I am in the UK, so my default paper/printer setting will be for A4 paper, if that makes a difference.
Edit:
It looks like my problems are caused by two lines further up in my program:
set(0,'DefaultFigurePaperOrientation','landscape')
set(0,'DefaultFigurePaperType','A4')
I think that becuase plots expect to be on paper with a portrait orientation, I am seeing these problems.
Perhaps I should revise my question to: what to I need to change in MATLAB figures so they print correctly on landscape A4 paper (ideally in the center, scaled to fill the page, but with correct orientation). All this without using Print Preview.
But I am going to do this instead to code around my problem.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
I can't seem to reproduce your problem on the computer I'm currently on (see the values I'm getting by default - Top is 8.11):
However, if your problem is what I think it is (I'm getting something that fits this description on another computer I'm working on), try adding _{ } at the end of your string. This is a TeX string meaning "subscripted space" which pushes the rest of the text slightly upward. You can also use ^{ } on the first line if the clipping is happening from the top. I found this workaround to work on axis titles and labels as well.
Exaggerated, the workaround looks like this:
titleString = sprintf('^{^{^{^{^{^{ }}}}}}Multi\nLine\nTitle');
Which shows the word "Multi" even for Top = -0.59.
If the above is not what you're looking for, you might want to look at the robust export_fig.
I can confirm that my clipping problems are caused by this line:
set(0,'DefaultFigurePaperOrientation','landscape')
I have revised my program to start with this instead.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
And the problem has gone away.
Users can still print in landscape if they use the print preview feature.
I am currently using the fill command in MATLAB to create a graph of boxes that were created using the 'fill' command (the actual code is based off this StackOverflow Question.
My issue is that the boxes that I create do not have "corners." I am attaching a PNG that illustrates the issue. Note that you have to look a little carefully since the image was heavily rendered, though in this example my arrows also look weird since they don't have edges either)
I am wondering if anyone has an idea of what might be going wrong? The boxes appear this way immediately after I use the fill command, which has the following structure:
fill(X,Y,MyFaceColor,'FaceAlpha',0.5,'EdgeColor', MyEdgeColor,'LineStyle','','LineWidth',box_line_width,'EdgeAlpha',1)
The function fill appears to leave space for corner markers if they are not explicitly defined. Hence, calling fill with the marker property will solve your problem. However, since markers and linewidths seem to work on different scales, you will have to play around with the marker size to get smooth edges.
Example:
fill(X,Y,'r','FaceAlpha',0.5,'EdgeColor', 'k',...
'LineWidth', 5,'EdgeAlpha',1 , 'marker', '.', 'markersize', 15)
I'm trying to create a plugin for flot that will draw axis that cross the origin (0,0) instead of only being shown at the edge of the plot. One thing I'd like to do is, when using my plugin, the drawing of the regular axis (the ones at the edge) should be suppressed. So I added some logic to a function that hooks into processOptions like this:
plot.hooks.processOptions.push(processOptions);
function processOptions(plot, options) {
if (options.crossOrigin) {
if (options.xaxis.crossOrigin) {
options.xaxis.show = false;
plot.hooks.drawBackground.push(drawXAxis);
}
if (options.yaxis.crossOrigin) {
options.yaxis.show = false;
plot.hooks.drawBackground.push(drawYAxis);
}
}
}
By setting options.xaxis.show to false (and the same for the yaxis), this is supposed to stop the axis from appearing, but it doesn't work. The option gets set, but flot ignores it when it draws the graph. The only way I can get it to not plot the regular axes is to explicitly set the show option when setting up the plot.
Any ideas why this doesn't work? Is there a way to make it work?
Update: So after playing around with this for a while, I think what is happening is that there is, for example, an options.xaxis and an options.xaxes (an array) which contains just 1 entry. For some reason, flot wants to use the 1 axis in the options.xaxes[0] instead of options.xaxis. But I'm not quite sure what the logic here is supposed to be. They both get my custom "crossOrigin" option merged in, but only the options.xaxis gets it's "show" property set.
Using xaxes[0] instead of xaxis seems to fix the problem, although it's not clear when and how flot is processing this stuff.
When I make a figure in Matlab, with a legend and a rectangle that touches the y axis (strange, I know) upon exporting the figure to eps (or pdf) I've noticed that the rectangle obtains the line-style of the last line drawn (rather than what the rectangle was drawn with)
This behaviour also occurs for rectangles drawn after the one that touches the axis...
This doesn't happen if the rectangle is drawn before the legend is created....
Needless to say, it took me half a day to create a minimal example:
clf
L=plot(X,sin(X),'--');
legend(L,'sin(x)')
rectangle('position',[0.001,.1,.7,.7])
rectangle('position',[0,.5,.6,.7])
rectangle('position',[0.001,.3,.5,.7])
%legend(L,'sin(x)')
On the screen the 3 rectangle have solid lines, as they should. but once they are exported, the result has the last two with dashed lines (like the sin(x)). If the legend command is done later (as in the commented out line), everything works as it should....
Is this a feature or a bug?
This is not a feature. I am submitting this to development.
You found a workaround that works with minimal code gymnastics. I would document it in your code so someone does not change it unknowingly and move on.
If you are open to other output formats, notice this is not an issue with formats that use an output filter of MATLAB.
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/print.html
(Graphic Format Files section, right column in table)
-Doug, Advanced Support at MathWorks dealing with graphical issues.
I have a question about the values returned by getPosition. Below is my code. It lets the user set 10 points on a given image:
figure ,imshow(im);
colorArray=['y','m','c','r','g','b','w','k','y','m','c'];
pointArray = cell(1,10);
% Construct boundary constraint function
fcn = makeConstrainToRectFcn('impoint',get(gca,'XLim'),get(gca,'YLim'));
for i = 1:10
p = impoint(gca);
% Enforce boundary constraint function using setPositionConstraintFcn
setPositionConstraintFcn(p,fcn);
setColor(p,colorArray(1,i));
pointArray{i}=p;
getPosition(p)
end
When I start to set points on the image I get results like [675.000 538.000], which means that the x part of the coordinate is 675 and the y part is 538, right? This is what the MATLAB documentation says, but since the image is 576*120 (as displayed in the window) this is not logical.
It seemed to me like, somehow, getPosition returns the y coordinate first. I need some clarification on this.
Thanks for help
I just tried running your code in MATLAB 7.8.0 (R2009a) and had no problems with image sizes of either 576-by-120 or 120-by-576 (I was unsure which orientation you were using). If I left click inside the image, it places a new movable point. It did not allow me to place any points outside the image.
One small bug I found was that if you left-click in the image, then drag the mouse pointer outside the image while still holding the left button down, it will place the movable point outside the image and won't display it, displaying a set of coordinates that are not clipped to the axes rectangle.
I'm not sure of what could be your problem. Perhaps it's a bug with whatever MATLAB version you are using. I would suggest either restarting MATLAB, or clearing all variables from the workspace (except for the image data im).
Might be worth checking to see which renderer you are using (Painter or OpenGL), a colleague showed me some wierd behaviour with point picking when using the OpenGL renderer which went away when using the Painter renderer.
Your code uses the Image Processing Toolbox, which I don't have, so this is speculation. The coordinate system is probably set to the figure window (or maybe even the screen), not the image.
To test this, try clicking points outside the image to see if you can find the origin.