What is the point???

[dunbarx]

Bernd.

I recall this sort of thing came up years ago right here.

Since the border has "real" thickness, it makes sense that one cannot define a rect that either measures to both the "outside" of that border in both opposite corners, or precludes them both. The only logical way forward, as your demo shows, is to split the difference, one in, and one out. Your point is correct that if the measurement starts at "0,0", that is, at the "outside" of the border, it then must finish at the "inside" of the opposite corner. It is the only way to balance the whole, since we are not dealing with mathematical lines, but real, bulky ones.

It was only happenstance in my original demo that I chose the particular corners I did. I bet that if I chose the botRight of the larger field, the result would have looked totally normal.

Craig

[Fjord]

I seem to remember a discussion about the maths of geometry problem with pixels in "Inside Macintosh" in an old, old, old edition. Something about points being thick etc. Sadly I had to throw away the book some years ago; if someone still has it, maybe this explains the problem.

[Klaus]

Could you please finally "resolve" the "Debugging and 'go cd x of stack y" thread?
viewtopic.php?f=9&t=39149

[stam]

Bernd.

I recall this sort of thing came up years ago right here.

Since the border has "real" thickness, it makes sense that one cannot define a rect that either measures to both the "outside" of that border in both opposite corners, or precludes them both. The only logical way forward, as your demo shows, is to split the difference, one in, and one out. Your point is correct that if the measurement starts at "0,0", that is, at the "outside" of the border, it then must finish at the "inside" of the opposite corner. It is the only way to balance the whole, since we are not dealing with mathematical lines, but real, bulky ones.

It was only happenstance in my original demo that I chose the particular corners I did. I bet that if I chose the botRight of the larger field, the result would have looked totally normal.

Craig

I wonder if maybe a better way to tackle this would be to define a new rect, at what the rect of the target anchoring object would be if borders were removed and use that to anchor objects instead - that is if u don’t want visible gaps.

[richmond62]

The main point seems to be that a pixel is not a point: and that one should ignore that at one's peril.

[dunbarx]

Stam.

I wonder if maybe a better way to tackle this would be to define a new rect, at what the rect of the target anchoring object would be if borders were removed and use that to anchor objects instead - that is if u don’t want visible gaps.

That is what adresdt posted a little back, where the borders were eliminated and the backColor filled in. The "points" of the two rects coincided, and all was right with the world.

Its the borders that misbehave, not the rects.

Craig

[dunbarx]

Richmond.

The main point seems to be that a pixel is not a point: and that one should ignore that at one's peril

Right, borders are ropes, not mathematical lines.

Craig

[stam]

We have no access to floating numbers for borderWidth/coordinates, so the distinction being made between pixels and points is an academic one, and one I’m not sure is even relevant.

As per the example I posted above, if you account for the borders you can line up as exactly as if no borders are present.

I was suggesting abstracting the “anchor” to a rect without the dimensions needed for the borders as a way to allow lining up from any approach, not just topRight to bottomLeft as in the code I posted above.

Whether you measure in pixels or points or bother to make a distinction is a bit academic as we can’t use decimal coordinates.

[richmond62]

Right, borders are ropes, not mathematical lines.

If there is a problem (and I am not sure if there is), it seems to be a problem somewhere between our expectations and what is written on the packet.

The result is that we have all been thinking for a long time that an address such as 12, 5 represents a point, when it would be better to think of an address a bit like a chess square (which is not a point):
-

-
At school we all learnt to plot graphs where 12, 5 would refer to a point: but a chess square is an area (on which one can place a chess piece (or even 2 in some variants) that itself has 4 corners.

[stam]

We’ll have to agree to disagree. Cartesian coordinates are Cartesian coordinates and not a thing that requires fuzzy logic.

At least until you can demonstate an actual application of what you suggest…

As far as I’m concerned I have provided this - but other that that philosophical musings, I haven’t seen and can’t really envision a solution that would take what you postulate and apply it in practice.

I would love to though as I’m more that happy to be proven wrong and learn… please do post an example…

[bn]

That is what adresdt posted a little back, where the borders were eliminated and the backColor filled in. The "points" of the two rects coincided, and all was right with the world.
Its the borders that misbehave, not the rects.

Craig,

The borders go "inwards", they do not add to the rect. The only exception for this is graphics made of points. Then the borderWidth adds to the rect. Which is fine since you want the geometry of the points.
Anyway left and top are within the rect, right and bottom "outside" of the rect.
The "border discussion" is a red herring.


If anyone still cares here is a stack that you can test all this.

Kind regards
Bernd

[FourthWorld]

We’ll have to agree to disagree. Cartesian coordinates are Cartesian coordinates and not a thing that requires fuzzy logic.

It's not so much fuzzy, as murky. . Or more specifically, ambiguous.

It boils down to whether the designer of the display system prefers Chess or Go: locations in Chess are spaces, while locations in Go are the borders between spaces.

When designing a display system, the question is whether the first pixel along an axis has a coordinate or 0 or 1.

(There's also the separate matter of where the origin point is. Most computer display systems place 0,0 at the top-left, though Postscript follows traditional geometry with 0,0 being the bottom-left. Going forward here I'll only refer to common display systems, and leave Postscript and high school geometry lessons for those environments.)

One might assume that since xTalks are among the minority programing languages that use one-based indexing (as with Pascal which was prevalent when HyperTalk was born, as opposed to C and the later scripting languages influenced by it which are zero-based), the first pixel would be "1", so an object at 1,1 would be flush to the left and top of the display.

But not so:

This pair of screen shots show a borderless gray rectangle on a yellow card. The left image has the graphic object's topLeft set to 0,0, the right image at 1,1. Antialising effects make this logical murkiness a tad murkier visually, but we can see the difference clearly enough.

So despite the rest of the language being one-based, xTalks have adopted the most common display architectural choice of referring to the origin point as 0,0, rather than 1,1.

This much is consistent with most geometry concepts, reminding us that these metrics are more Go than Chess: they describe boundaries, not spaces.

Most of the time it hardly matters, but when scripting object alignment we may from time to time need to remember that the edge of a visual element is defined not by the pixel we can see but by the logical boundary at the pixel's edge closest to the origin point.