From: Fernando P. <Fer...@co...> - 2005-02-02 19:30:40
|
Fernando Perez wrote: > John Hunter wrote: >>But using non-equal width and height for the axes seems like a logical >>error that defeats the stated purpose of matshow. Of course, in real >>life this might be a hack to defeat unequal dpix and dpiy on your >>monitor, but it would come back to bite you when you saved to PS, >>which has the same dpi in both directions. > > > Well, the problem is really the following: we need at least 0.15 on the left > to leave enough room for the row ticks. Those can grow reasonably wide, given > that a 1000 row array forces 4 character labels. OTOH, the labels at the top > are all a single character tall, so they don't occupy quite as much space. I > was trying to balance these constraints, by moving the image to the right just > enough, while trying to avoid a too wide band atop the figure. But your > aspect ratio comment is valid, so perhaps the height should be reduced to > 0.75. You are correct that matshow should, when at all possible, guarantee an > exact aspect ratio. This is especially important for generating array > displays in EPS for papers. > > But it's important to leave at least 0.15 on the left, otherwise for tall > arrays the labels are lost against the wall. To close this off, here's a set of numbers ax = fig.add_axes([0.15, 0.09, 0.775, 0.775]) which: - respect x/y scaling constraints - allow up to 4 character labels (arrays with >1000 rows) to display - center the image reasonably without unnatural space when possible. These are the numbers I'm keeping for now in my tree. And now I'll shut up on this one. It would still be possible to improve the layout for the extremely tall/wide cases, but that would require a bunch of special-casing code and fine testing. At this point, even I am willing to say 'good enough'. And now I'll take my meds :) Cheers, f |