Thanks to everyone who suggested workarounds. But I want to emphasise that I don’t want a workaround — I want Matlab to do the right thing out of the box. And although I didn’t get into this in my original post, I’ve already spent entirely too much of my life trying different ways of getting figures out of Matlab and into Word. And this is just hugely frustrating, especially since the year is currently 2007, and you’d think this sort of thing would “just work” by now.

But given that things don’t “just work”, here’s my current favorite workaround: I use the “print” command to save figures as Encapsulated Postscipt (with the renderer set to painters), use Ghostscript to rasterize them to PNG images at 300 DPI (with antialiasing), and then import them into Word. This produces beautiful images, which look nice onscreen, and also look reasonably good when printed. The print quality isn’t as good as if I had just imported the EPS files directly into Word, and of course it’s very cumbersome (compared to Ctrl-C, Ctrl-V), but the onscreen quality is much better, and after much deliberation I’ve decided this is the tradeoff I dislike the least.

So, for my favorite method, here are the pros and cons:

Pros:

• Optimal on-screen quality
• Good print quality

Cons:

• Print quality, though good, is suboptimal
• Cumbersome

Okay, so that’s the solution I like. What about all the other possible solutions? What are the pros and cons of them? I’ll go list these for a number of methods below, but first let me state what I want from a perfect solution:

• As fast as Ctrl-C, Ctrl-V
• Perfect print quality: I want the figure to look the same when I print my Word document as it would if I printed it directly from Matlab. In practice, this means that the format used to interchange the figure has to be a vector format (and it probably has to be Postscript if it’s to work really reliably).
• Perfect onscreen quality: When I look at the Word document onscreen, I want the quality to be at least as good as when I’m looking at the figure in Matlab. (Actually, using the method above the figures often look better in Word than they go in Matlab, because Ghostscript can be made to do better antialiasing that Matlab does!)
• What You See Is What You Get (WYSIWYG): The figure should look the same in Word as it does on-screen in Matlab. Exactly the same.*

Okay, on with the list! (I should mention that this is all based on my experiences using Matlab R2006b and earlier under Windows XP and earlier.)

Cons:

• Doesn’t work (see previous post)

Pros:

• Pretty fast

Cons:

• Not as fast as it could be
• Figure is at screen resolution, which is lousy

Pros:

• Pretty fast

Cons:

• Not as fast as it could be
• Metafile “resolution” is the screen resolution, which is lousy
• Word draws metafiles slowly, and with no antialiasing

Comments:

Some will object that Windows metafiles, being a vector format, have effectively infinite “resolution”. Sadly, this is not the case. While that’s basically true of most vector formats (like Encapsulated Postscript), Windows metafiles specify the coordinates of all vector objects as distances measured in pixels, and fractional pixels are not allowed. The file format specifies the size of the image in physical units (millimeters, as it happens) and in pixels, and then all of the vectorial descriptions of where to draw things are all in (integer) pixels. So you can achieve resolutions that are as high as you would like (by setting the size of the image in pixels to be something very big), but it still makes sense to talk about the the “resolution” of a metafile. And when you “Copy Figure”, the size in physical units is the on-screen size (in mm), and the size in pixels is the on-screen size in pixels. Hence, screen resolution.Furthermore, Word seems to handle metafile drawings like the proverbial red-headed stepchild. A metafile with many elements is slow to draw, and there is no anti-aliasing.

Cons:

• Doesn’t work

Comments:

In theory, the “-r1000″ is to make sure you get vector objects with precisely-placed endpoints. Sadly, this method elicits a bug in Matlab (Bug Report 346322, unfortunately a login is required to view it). It seems to sometimes work once, but then elicits an error the second time you try it. (Late update: The Mathworks seems to have addressed this in R2007a by just having “print -dmeta” ignore the “-r” switch, and just output it at the screen resolution. Way to punt, guys, way to punt.)

Cons:

• Doesn’t work

Comments:

This elicits the same bug in Matlab as the previous method. (This also seems to have been not-fixed in R2007a, see above.)

Pros:

• Fair on-screen quality
• Fair print quality
• Faster than rendering to an image via Ghostscript

Cons:

• Print quality suffers because image is not anti-aliased

* There’s a little bit of an issue here, because of the way Matlab handles the printing of figures. With the default settings, Matlab figures sometimes look different when printed then they do on-screen, because Matlab has both an on-screen size for the figure and a completely independent printed size. And even if you set these to be identical, Matlab still re-optimizes the tick marks and other things when you print. In my opinion, Matlab should jettison all of this stuff and just support What You See Is What You Get (WYSIWYG) printing of figures. (Or at least have that be the default.) It would just simplify everything.

Suppose I want to take a Matlab figure, copy it to the clipboard, and then paste it into a Word document. Furthermore, suppose that I want it to look decent if I then print the Word document. To make this happen, the image that is copied to the clipboard has to have a resolution of at least 300 dots per inch (DPI). Even the first laser printers printed at 300 DPI, and current laser printers typically print at 600 DPI. Typical monitor resolutions are much lower — even a good LCD monitor today is typically only 100 DPI. So copying my figure into Word at the monitor resolution is just not going to cut it. A 100 DPI image looks terrible when printed. I need it to be at 300 DPI at least, and I might very well want it to be higher.

So, when I select “Copy figure…” from my figure’s Edit menu, I want a 300 DPI image of what’s on my screen copied to the clipboard, so then when I go and do Edit > Paste in Word, I get a beautiful 300 DPI image in my Word document. You’d think this wouldn’t be that much to ask, right? I want to take my Matlab figure, paste it into a Word document, and have it not look like crap when printed. Surely, more than twenty years since the advent of the graphical user interface, what-you-see-is- what-you-get, and desktop publishing, this is all old hat for any application worth its salt. Right? Well, not so much…

In Matlab, there is no way to get “Copy Figure” to produce a bitmap that is at any resolution other than the screen resolution (as of R2006b in Windows XP). In the preferences, you can configure several aspects of Matlab’s copy-and-paste behavior, but not the resolution of the final bitmap. You always get it at the screen resolution, which is almost never adequate. Roughly twenty years after this capability should have been part of Matlab, it’s still not present.

On the whole, I think Matlab is a beautiful piece of software. I use it every day, and most of the time I enjoy the heck out of it. It’s very simple and very powerful. But when I’m done analyzing my data, I almost always want to take a figure from Matlab and export it to some other program. This is exactly what copy-and-paste is for, but Matlab’s implementation of copy-and-paste is so broken that I always end up saving my figure to a file and then importing that file into the target application, which takes about ten times as long as copy-and-paste would. If I only did this once a month, it probably wouldn’t make me as insane as it does. But I do it maybe ten times a day, almost every day. Twenty years ago, some wise person at Apple (or maybe Xerox PARC) had exactly the same problem, and invented a solution for it: copy-and-paste. But twenty years later, The Mathworks still hasn’t gotten the memo.

This should be fixed in the next release of Matlab. It should have been fixed a long, long time ago, so fixing it now is really the least The Mathworks could do. If Cleve Moler were here, he would say the same thing.

And another thing: Why do I even have to do Edit > Copy figure to do the copy? Why not just Ctrl-C, like every other application on the planet? In Matlab figures, for some reason, Ctrl-C is used when you decide to edit a figure, and select some element of the figure you want copied to the clipboard. I myself have never used this functionality, and I don’t think I’m the only one. Has The Mathworks looked at how often that’s used compared to “Copy figure”? I would bet almost anything that “Copy figure” is the more commonly used function. If I’m right, it seems like it should be bound to Ctrl-C, not that other function. And in any case, couldn’t Ctrl-C be bound to “Copy figure” if the figure is not being edited?