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.
Related
I am using Export_fig to export figs from matlab, I am getting very good plots generally. But when i add some textboxs and arrows in the fig. the clarity is pathetic.
I use the -transparent property, which does not work either.
export_fig('path', '-pdf','-transparent')
Anyone knows what is happening here. Normally this works very good, only when the text is added it acts like this way. Not sure if it's a glitch in the code or if i am doing anything wrong.
Note: I added the text and arrows with insert option on the menu bar.
If you are not set on using Export_fig for other reasons, consider using MATLAB's built-in print function and increase the resolution with the -r attribute
print('path', '-dpdf', '-r300')
where 'path' is the desired 'path\filename.pdf', '-dpdf' sets the file type, and '-r300' sets the resolution to 300 dpi, also try '-r0' for screen resolution, or higher, till you get what you want.
I'm not sure what the '-transparent' argument is used for but there is probably an equivalent you can find in the documentation.
https://www.mathworks.com/help/matlab/ref/print.html
I am using jupyter-notebook to write some python code and generate figures. As I wanted to add tooltips on mouse hovering and other interactions with the generated graphs, I now use mpld3 to display the graph.
However, as I have quite a lot of things to plot, I need to increase the figure size. So, I putfig = plt.figure(figsize=(20, 10)).
When I display with the standard way, I can see all the figure in my notebook (with horizontal sliders if I increase a bit more the figsize).
But with the mpld3 display, the size of the zone where the figure is displayed seems to be fixed, and hence, I can only see the upper left part of my figure. There are no sliders or anything to increase the displaying zone size.
For example, this code generate a graphic, for which you will see only the upper left part:
fig = plt.figure(figsize=(20, 10))
plt.plot([3,1,4,1,5], 'ks-')
mpld3.display(fig)
Does anyone know how to deal with this ? That is, how to increase the default display zone size, in order to have bigger graphs ?
Thanks
Edit after comment:
Here is a screenshot of how it is displayed on my machine...
And I would like it to be displayed just as it is on yours !
So I guess the problem comes from elsewhere... do you have any idea of how to solve this ?
I hope I do understand your question correctly but in Ipython Notebooks you can only use excisting space and not flip the notebook into wide screen mode or alike. In my notebook the graphic is also displayed like you show.
However, there is an easy fix, simply reduce the figsize to for example (10, 5). The main idea with interactive plotting with mpld3 is that the user can zoom in to specific interesting details. For the presented example it would not make much sense but richer graphs are great to be explored interactively.
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)
Is there any way to print the figure to the clipboard so that the quality is identical to what the Edit-->Copy Figure option provides?
I used to save the figure to powerpoint file by using saveppt.m obtained from Matlab Central. It worked well until yesterday. I noticed that the stored image quality was somehow degraded. I tried to re-generate some ppt slides with exactly the same script and the same source data, but the new slides are simply of worse quality.
I investigated into this problem a little bit and discovered that when the figure is copied to clipboard by running print -dmeta, the image in the clipboard is already degraded, while if I use the Edit-->Copy Figure option in the figure window, I get the image as clear as the original image in the figure window.
Following is an example for your reference. I copied the image from a figure to the clipboard by two different methods, and paste it to Microsoft Paint program, and cut a piece of it to show below:
The image using print -dmeta:
The image using Edit-->Copy Figure:
If you compare the Xtick label '50', you may see that the image from Edit-->Copy Figure is smoother.
At the beginning I thought it was a problem of the resolution, but setting -rN to change the resolution does not seem to resolve my problem, at least not for N<=300.
Thank you for your help.
The short answer... Use the same function invoked in the callback for that menu item:
editmenufcn(gcf,'EditCopyFigure');
The longer answer... How exactly did I find this? You can look at my previous answer to a related question about reproducing what is done by a File menu option. The concept is the same, just for a different figure menu. For example, this will find the callback you want for the currently active figure window:
>> hCopyFigure = findall(gcf,'Label','Copy &Figure'); %# Handle for the "Copy
%# Figure" menu item
>> get(hCopyFigure,'Callback') %# Callback invoked when that item is selected
ans =
editmenufcn(gcbf,'EditCopyFigure')
The function EDITMENUFCN is another one of those sparsely documented functions, but looking through the code (by typing edit editmenufcn.m) shows that it either invokes Java (if you're on a Mac) or the undocumented function UIMENUFCN.
I think I found the answer myself. Using print -dmeta -painters to specify the renderer resolves my problem.
In File-->Preference-->Figure Copy Template-->Copy Option I noticed there are 3 options:
Metafile
Preserve information
Bitmap
I found that if I select 1, the Edit-->Copy Figure outputs the same image as print -dmeta. So I kind of confirmed the information I need is in the Preserve information option. A quick google search led me to the discussion about the potential difference of the applied renderer, and eventually I confirmed that using painters will print the image to the clipboard in the way I wanted.
The image in the question seems to be generated by the renderer zbuffer and painters, respectively. I still don't know why the default renderer of paint -dmeta changes, though.
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.