Re: Object Graphics v0.3

On Tue, 7 Mar 2006, Shai Ayal wrote:

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