Re: [TCLCORE] Purpose of mmObjType vs pixelObjType

[Alexandre F. <ale...@gm...>]

On Mon, Nov 10, 2008 at 4:57 PM, Kevin Kenny <ke...@ac...> wrote:
>
> [regarding pixelObjType and  mmObjType]

Thanks for the perspective Kevin. It dissipates a finite (as in :
nonzero) proportion of the mystery ;-)

> Tk, by design, tried very hard to keep all measurements in millimetres,
> because doing so had some chance at keeping more or less the same
> appearance of a GUI at all screen resolutions.

Of course. But this only mandates the possibility (which is present
today) of providing all screen distances in you preferred unit. In
string world this is a piece o'cake (1mm, 2i, 3cm).
This does *not* tell anything about how things should be handled
internally though. The very same external contract can be fulfilled
with several alternative implementation choices...

> both millimetres and pixels were implemented.  These objects, like
> all Tcl objects, tended freely to shimmer. An object simply had
> whatever representation was requested last.

What's funny is that in today's [coords] issue, pure Tcl_ObjType-based
lazy conversion would handle the job better than the actual code.
As it turns out, [coords] is fed distances in pixels (meaning that
numbers without decoration are interpreted as pixels), and when
requested to spit them back out it must also give back pixels. Here it
turns out that there is a parasitic quasi-shimmering (not even a true
one) to millimeters. But contrarily to other situations there is no
good reasons to shimmer, since nobody on the data path is client of
the millimeter form !

> Lossless conversion isn't possible or desirable in all cases,
> of course.  Someone who, for example, scales an object on a
> canvas by a factor of 0.1 and then scales the result by 10.0
> is not going to get the same object back. It's not going to
> happen.  But for simple arithmetic on the screen metrics, it
> probably should.

Yes it should. Store-and-retrieve, in the natural unit of the canvas
which is the pixel, should be a no-op.

> One possibility - I don't know how reasonable this would be -
> would be to carry screen dimensions over the lowest common
> denominator of points (or Microsoft's twentieths-of-points?),
> mm (or microns, perhaps?) and pixels.  Such a representation
> would be an integer almost all of the time, perhaps yielding
> less chance of losing precision on the way.

You're aiming higher than I was :-)

I'm working with the naive idea that as soon as a screen distance is
provided with decoration (letters giving a unit), all claims of
losslessness are lost, while naked numbers (integers or
floating-point) should be protected as much as possible.
This approach doesn't need to resort to integer-numbers-of-common-subunit.

> I know, I've made things less clear, not more -- but it's
> important to remember that some of these things Just
> Happened.

I propose to just patch Tk_CanvasGetCoordFromObj so that it calls
GetDoublePixels instead of the current shenanigans.
Any objection ?

-Alex