From graphics-request at octave dot org Mon Mar 6 22:50:07 2006 Subject: Re: Object Graphics v0.3 From: "Shai Ayal" To: "Bill Denney" Cc: graphics at octave dot org Date: Tue, 7 Mar 2006 06:48:24 +0200 On 3/6/06, Bill Denney wrote: > > Units: Matlab supports a multitude of units -- pixel, point, cm, > > inch,... So I'm not sure what the minimal requirements should be. > > 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. > The reason I dislike this is because if I have to think about physical > distances while making a figure then I have to think about the conversion > that I want to do instead of the general look of the figure. > > > ticklength -- while specifying it in percent of the axis scale seems > > natural, It turns out to be "ugly" -- some things just look better if > > they are a fixed number of pixels whatever the axes scale is. It's > > like text -- it's size has to specified in points/pixels and not in > > axis units. > > 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 > > 3D: I am not planning to implement it soon, so I have many suggestions :) > > I think that you should add all the camera, lights etc.. properties. > > Most 3D tool kits support it anyway (I know OpenGL does), so it really > > does not complicate the code much. > > OK, I'll look into the camera, light, etc. properties and come up with > some suggestions for version 0.4. > > > layering: > > I think it would be more clear to write first child on the bottom, > > last child on the top > > I thought that was what I had written. Could my writing be made more > clear somehow since what you describe was definitely my intent. > > > legend object: > > This is my creation and does not exist in matlab. Of course I am > > flattered that you like it, but I think you should reconsider whether > > it should be in the spec. > > I think that it makes sense as a separate object because of the fact that > it is the only type that I can think of that will be linked to another > type. In other words, it has the special property that it will draw > generic lines but not use the line data, so it may have children that are > also children of another object. > > > compatibility: > > We should probably add some query functions like: > > propnames(handle) to return call array of strings with the names of > > all properties, > > isproperty(handle,propname) to find out of the object supports the property. > > the user can use these to develop cross-backend apps. > > OK, I'll add that to the spec. > > > Also, I think that get(handle) should return a structure with fields > > corresponding to the properties and values corresponding to their > > value, like in matlab > > That was what I planned on it doing; I'll specify that as well. > > Bill > > -- > "What if they call the Cops?" -- Ted Johnson > "You run. That's the most exciting part of trick or treating naked for > UNICEF." -- Nick > -- Red Meat, 10/22/2002 > >