Flow/wrap text into an irregular shape--was briefly: use-livecode Digest, Vol 123, Issue 56, my mistake

[James Hurley]

Hi Bill,

Good point Bill. There is that possibility. But given LC level of precision, it doesn’t seem to be a concern.

As a test, I used the Polygon handler to draw a polygon with 10,000 sides, each side 1 unit in length—for all practical purposes, a circle.

The figure closed. To confirm the closure, I checked the 1st and 10,000th points. 

The first point was 337,253
and the last point was 337,253

I learned  something I was unaware of. In RunRev v. 5.02 all the graphic points had to be whole numbers. You could set the loc of a button, field, graphic etc. to fractional numberers, but they were not allowed as graphic points. I recall putting in a request to allow for full decimal point precision in the graphic points, and, lo and behold, I see in LC v. 6.5.1 that is indeed possible. 

It wasn’t just a matter of precision, but if you unknowingly set a fraction point among the grc points, the graphic didn’t display at all. So I would go looking for a mistake in the code and it would sometimes take me a while to realize is this quirk in RunRev at that time. 

Very happy to see that fix.

Jim




> Message: 5
> Date: Tue, 31 Dec 2013 08:37:23 -0800
> From: Earthednet-wp <prothero at earthednet.org>
> To: How to use LiveCode <use-livecode at lists.runrev.com>
> Subject: Re: use-livecode Digest, Vol 123, Issue 56
> Message-ID: <F1D8616A-B8BE-4218-8D5B-25DF3CB2B73B at earthednet.org>
> Content-Type: text/plain;	charset=utf-8
> 
> Jim,
> One of the things that worries me when setting up a system where each new point (or line segment) is drawn relative to a previously drawn position is the possibility of errors creeping in due to rounding of non integer numbers. I am usually plotting decimal numbers and I always want to know the precise position of each point before I round it to an integer pixel location. For example, if an initial position is 1,1 and multiple moves are 1,1 but rounded down from 1.4,1.4 pretty soon you have lost a pixel. Say, 3 moves would end up, non rounded, to 4.2,4.2 but if the destination is rounded at each step, you would only have a net move to 3,3. The errors could add up.
> 
> Perhaps you've guarded against this, as I haven't looked at your code in that much detail. My approach to guard against this is to always calculate to destination point, then do the rounding.
> 
> Best,
> Bill
> 
> William Prothero
> http://es.earthednet.org
> 
> On Dec 31, 2013, at 7:51 AM, James Hurley <jhurley0305 at sbcglobal.net> wrote:
> 
>>> 
>>> Message: 12
>>> Date: Mon, 30 Dec 2013 19:04:04 -0700
>>> From: Roger Guay <irog at mac.com>
>>> To: How to use LiveCode <use-livecode at lists.runrev.com>
>>> Subject: Re: Flow/wrap text into an irregular shape
>>> Message-ID: <EF2CF37D-27DD-47AA-9F23-C3C5920943CB at mac.com>
>>> Content-Type: text/plain; charset=windows-1252
>>> 
>>> Jim,
>>> 
>>> Could you please briefly explain this distinction between Euclidian and Cartesian geometry as it applies to Turtle Graphics?
>>> 
>>> Thanks,
>>> 
>>> Roger
>>> 
>>> 
>>>> On Dec 30, 2013, at 10:08 AM, James Hurley <jhurley0305 at sbcglobal.net> wrote:
>>>> 
>>>> The basic advantage of TG is that it speaks a language closer to Euclidian than Cartesian geometry.  
>> 
>> 
>> Hi Roger,
>> 
>> Good question. Best answered with an example. Euclidean geometry is concerned with shapes (lines and angle), while Cartesian geometry is concerned with points in a Cartesian coordinate system. 
>> 
>> A script for a Cartesian polygon might look like this:
>> 
>> on mouseUP
>>  drawPolygon 6,100
>> end mouseUP
>> 
>> on drawPolygon N, L
>>  --draw an N side polgon with sides of length L
>>  set the points of grc "poly" to ""
>>  put trunc( the width of this card/2) into x0
>>  put trunc( the height of this card/2) into y0
>>  put x0 into xOld
>>  put y0 into yOld
>>  put 0 into tAng
>>  repeat N+1
>>    ?Draw each side relative to its predecessor
>>     put xOld + L* sin(tAng*pi/180) into xNew
>>     put yOld + L * cos(tAng*pi/180) into yNew
>>     put xNew,yNew & cr after tPoints
>>     put xNew into xOld
>>     put yNew into yOld
>>     add 360/N to tAng
>>     ?set the points of grc ?poly? to tPoints; Use this if you want to see the polygon evolve
>>  end repeat
>>  set the points of grc "Poly" to tPoints
>> end drawPolygon
>> 
>> That script is full of Cartesian coordinates and trig.
>> 
>> The same polygon may her accomplished in TG with something like this:
>> 
>> on drawPolygon N, L
>>  startTurtle --
>>  repeat N 
>>     forward L
>>     left 360/N
>>  end repeat
>> end drawPolygon
>> 
>> The script if nothing but lengths and angles.
>> One might a easily construct a handler to draw an N sided polygon whose circumference is C:
>> 
>> on drawPolygonGivenCircumference N, C
>> st
>> repeat N
>>   fd C/N
>>   left 360/N
>> end repeat
>> end drawPolygonGivenCircumference 
>> 
>> Of course RunRev recognized the complexity of analytic, cartesian geometry in such cases and introduced several drawing tools: Rectangle, Line, Oval, Freehand curve, Polygon, Regular polygon, to deal with these special cases.
>> 
>> But I have also built into TG the ability to handle Cartesian geometry as well, with such functions as xCor(), yCor(), xyCor(), direction(), etc. for there are times when that is the best route to take. How else would one draw a parabola. (y = x^2)
>> 
>> Jim
>>