From graphics-request at octave dot org Mon Mar 6 23:02:22 2006 Subject: Re: Object Graphics v0.3 From: Bill Denney To: Shai Ayal cc: graphics at octave dot org Date: Tue, 7 Mar 2006 00:03:49 -0500 (EST) On Tue, 7 Mar 2006, Shai Ayal wrote: > On 3/6/06, Bill Denney wrote: > >> I want to support many units, but I don't like the idea of there being a >> real-world unit specified in the middle of the figure. This is because >> allowing for a mixture of units adds significant confusion to the figure >> implementation. Perhaps we should have a figure level conversion between >> pixels and physical world units, a property to figure-level objects that >> would be something like PixelsPerDistance that would be a 2x1 cell vector >> containing a number and a unit type (like "in" or "cm" or "pt") then any >> distances given could be converted to the appropriate units for the figure >> by the set command. > > It's an interesting idea. I'll have to think about it. I actually just had an idea about how this could be very nice: it would allow programs to have monitor calibration (hold a ruler up to the monitor and measure out the pixels when the backend displays a pixel bar) and images could come out on paper looking the _exact_ same as they do on screen. If this idea flies, are pixels always square on monitors, and if not, should it be defined by a 1x2 double vector as the first cell with vertical and horizontal pixel dimensions? >> But what about backends that don't have a distinct unit of "pixel" such >> as any form of paper-like backend? I don't like using pixels because >> they vary with display device while other scales don't vary. > > Well, how about thinking of tick marks not as a graphic elements such > as the axes bar, but as a text element, such as the ticklabel -- this > is more appropriate IMHO,. So tickmarks can be specified in points > like text size That makes more sense to me; I'll change it. Bill -- 1-800-578-7453