Prev: reduce step size error
Next: Simulink/GUI thread interaction
From: arich82 on 14 Sep 2009 17:12
Can anyone explain the "default" -r864 for the command line print function using -depsc2. The help info states this to be the default for non-image, non-metafile formats (what's left?), but the doc makes no mention of it in 2007a. (For what it's worth, I'm using Mac OS X.4.)

When is this value actually used? When should it be used? Does it actually represent 864 dots-per-inch (this seems excessive, and doesn't mesh with the size of the output I'm seeing)?

export_fig from the FEX uses this setting, and it's giving me a hash-like pattern (vertical, horizontal, and 45-degree lines) in regions of my surf plots with solid colors; changing the flag alleviates the problem. I'm not hooked up to a printer, so I can't verify that the hashing isn't just a display error, but a pdf made from the eps file allows me to zoom in on the hashing so it seems 'real'.

Any suggestions on a more appropriate setting for publication quality plots? Perhaps -r300? I've read numerous threads claiming the -r flag doesn't always set the actual dpi...
From: Oliver Woodford on 15 Sep 2009 09:17
"arich82 " wrote:
> Can anyone explain the "default" -r864 for the command line print function using -depsc2. The help info states this to be the default for non-image, non-metafile formats (what's left?), but the doc makes no mention of it in 2007a. (For what it's worth, I'm using Mac OS X.4.)
>
> When is this value actually used? When should it be used? Does it actually represent 864 dots-per-inch (this seems excessive, and doesn't mesh with the size of the output I'm seeing)?
>
> export_fig from the FEX uses this setting, and it's giving me a hash-like pattern (vertical, horizontal, and 45-degree lines) in regions of my surf plots with solid colors; changing the flag alleviates the problem. I'm not hooked up to a printer, so I can't verify that the hashing isn't just a display error, but a pdf made from the eps file allows me to zoom in on the hashing so it seems 'real'.
>
> Any suggestions on a more appropriate setting for publication quality plots? Perhaps -r300? I've read numerous threads claiming the -r flag doesn't always set the actual dpi...

I think that with vector graphics the "resolution" determines the accuracy of the positions of vertices. I've seen these kind of artifacts myself and have neverly really understood what caused them. Perhaps they're caused by rounding errors whose effects vary depending on "resolution". It would be interesting to know if you see them when you increase the resolution as well (e.g. try -r2000).

If -r300 works better for this particular plot then you should use it, but I don't think any general statements can be made regarding which resolution is better for publication figures - it will depend on the content of the figure and also the size of the figure on screen relative to its size on the page.

Oliver
From: arich82 on 15 Sep 2009 11:49
Oliver--

Thanks for the reply (and for the export_fig FEX submission). I'm finding that the hash pattern artifacts in the solid colors are actually due to using 'painters', and not the resolution.

I was erroneously comparing the output of your function to the command line print, forgetting that the '-painters' flag was hardcoded in your function to get the vector graphics for eps/pdf files, while the command line defaults to '-zbuffer' for my surf() plots. I think I'm going to shoot for a hybrid between your function and the old exportfig with epscombine to get vector graphics for fonts and axes, with 'zbuffer' for the surf() field.

I'll let you know if the behavior of '-painters' changes after I upgrade to OS X.6 and MATLAB 2009b.

Thanks again.


--Andy
 | 
Pages: 1
Prev: reduce step size error
Next: Simulink/GUI thread interaction