Re: Object Graphics v0.3

On 3/6/06, Bill Denney <[email protected]> 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
>
>