Article:  |
Introduction to Cocoa Graphics, Part 2 | |
| Subject: | happy you figured it out | |
| Date: | 2001-11-20 22:29:03 | |
| From: | psheldon | |
|
Response to: thinking in box, curve out of box ;-)
|
||
|
Now, 12:30 A.M. I'm anxious and excited to try out the code and follow your story and see if I can grasp what is going on. I'm sure happy that os 10.1 allows me to connect to my internet computer's lower os 9 appletalk and port over the sample code you give . I shall comment it (take notes on it) and read your story to get the connections going in my head. At first I can be pretty dense, so I better hold off until morning or I'll get in the wrong frame of mind to sleep. But, I'd sure like to peak at it. Do you know the feeling? |
||
Showing messages 1 through 4 of 4.
-
The plot thickens!
2001-11-21 06:40:57 retro [View]
-
The plot thickens! So does the fluted R.
2001-11-21 14:20:42 psheldon [View]
second paragraph :
You are hotter to what your wrote , is ugly line related to the line to the flute on the R end? cf tool for fluted ends of fonts, serifs (?) .
3rd paragraph :
Weakness might be merely for certain values or uses. A tool has a weakness for what you want, you pick up another tool. You're "the man" or artist, you choose, moment by moment. Values change. You want to make some sort of object that draws an R with flutes, you value this, if you want to draw roses, there are other tools.
I think, because I went off on a tangent of finding the postscript context, I have some sort of hindsight you missed.
Does my fluted R vision help you with the conceptualization?
-
Absolutely
2001-11-21 05:34:53 retro [View]
I was up late last night still trying to completely grasp what this function does, and I am doing so right now. I tried, for instance, to make a perfect 100x100 square, and attempted 4 iterations of this command to attempt to draw a flower-like picture. I assumed that the radius of the arcs, 50, would cause a series of half-circles to be made, but I was mistaken.
In fact I believe that the arcs made by this function are actually quite different. The first tangent is made between the initial (appended-to) point and the "fromPoint", the second tangent is made with the "fromPoint" and the "toPoint", as if the two points defined an arbitrarily infinite line for the arc's radius to match properly. You know, its amazing - I didn't fully understand this until I started writing this reply. Trying to explain it to you brought understanding to me.
I have uploaded a picture:
http://homepage.mac.com/abenassi/Images/ArcAndGuide.pct
Here is the new code, which I finally completely grasp:
- (void)drawRect:(NSRect)rect {
#define SIDE_LENGTH 100
float bottom = 100;
float left = 100;
float top = bottom + SIDE_LENGTH;
float right = left + SIDE_LENGTH;
NSPoint bottomLeft = NSMakePoint(left, bottom);
NSPoint bottomRight = NSMakePoint(right, bottom);
NSPoint topRight = NSMakePoint(right, top);
NSBezierPath * arc;
NSBezierPath * guide;
[[NSColor blackColor] set];
// Draw the arc itself
arc = [NSBezierPath bezierPath];
[arc moveToPoint:bottomLeft];
[[NSColor blackColor] set];
[arc appendBezierPathWithArcFromPoint:topRight toPoint:bottomRight radius:60];
[arc stroke];
// Draw the guide from which the computer creates the arc
guide = [NSBezierPath bezierPath];
[guide moveToPoint:bottomLeft];
[guide lineToPoint:topRight];
[guide lineToPoint:bottomRight];
[guide stroke];
} -
Absolutely --- ah I see two tangential
2001-11-21 14:52:20 psheldon [View]
Paragraph 2 :
I hadn't seen this. Thank you. So, forcing my mind to stretch along my theory as well. You start the leg of the R on each side of the fill and pull the leg with the method to the end of the flute. I think with your direction of the end control, you have two have arguments switched to have it flute each way.
You wrote : "Trying to explain it to you brought understanding to me".
Finding out that writing something to explain to Rockwell Space Division, I was actually explaining it to myself was a life changing experience. In industry, you have those who move up by copying politically correct statements and believing them. People have thought that whenever someone talks to some other, someone is wasting someone else's time because one person must be learning and the other finding him a parasite. Others have thought both people are wasting time. Some supervisors are jealous of other people talking to each other because that takes "power" away from the supervisor and you should report through formal channels of command. Others brow beat you for wasting the valuable supervisors time talking to him. Should should should, all a mockery for job security in Rockwell Space Division. If you can should someone else you are holier than thou in SoCal and that works to get you job security (or, at least, that is the way a senior there explained it to me).
My life changing experience was to go to each individual with one paragraph and ask what was the worst, most incomprehensible, sentence in that paragraph. The people, not a specialist in what I was hot to, found that very easy, even though they were astonished that I would ask them such a question. Everybody in the think tank read one of the paragraphs and picked the awful sentence and I rewrote each of those sentences. I got smart from everyone elses complaints, didn't noticeably bother them because they didn't have to understand anything just say what single sentence they least understood in a single paragraph. I cited them all!
Analogous to Captain Kirk I hope I can continue to believe that "I don't believe in the win lose scenario", though his was the Kobyashi Maroon (sp?) "I don't believe in the no win scenario" cheat.
You might summarize my attempted inspiration with intuition transcends formal channels of communication. Formal channels of communication are from a funny book, "The Psychology of Computer Programming" .
Paragraph 3 :
I saw the picture. You have remembered some lesson I forgot or know how to make a screen shot in os x. Cool. We have a new window on results we can show each other. The picture clearly illustrates the two tangent matching ends of the arc. I found the picture easy to refer to rather than rerunning the code. I then grasped the new concept you found.
Well, now I think I should rest and watch Robin Hood Prince of Thieves with Kevin Costner.
An interesting thing I found: When you draw the arc, it conforms to the angle from which you have created. However, if you append to the arc, it does not append to the ever-floating end of the arc, but to the "toPoint:" argument (!). That means the computer will go back and connect itself, thus drawing an ugly line where none originally existed. This intuitively does not make sense, but from a computer programmer's point of view it is necessary.
One of the weaknesses of this function is it's reliance on static points. If you want to make a continuous path, you _have_ to know that your end point is at precisely the point at which the arc becomes tangent to the second line. The second point of tangential contact is equidistant from the apex as the first point of tangential contact. Using manual drafting means, you could discover these points by drawing an arc using the apex as the center point for your compass. You could then find the arc's center by drawing two separate arcs of the desired radial length from each of the two end points, the center being at the intersection point. Then finally, you would draw the arc while carefully erasing all of the other lines.
Unfortunately, we do not have the convenience of a compass to measure where the second point should be. Up to this point it has just been a static point. This is insufficient. We need to find a way to calculate this point and have it change automatically to accommodate the changes in the arc's radius. We need to do the same for the starting point, as I have noticed the arc does not necessarily start at our starting point, but wherever it is mathematically to do so. The starting point, fromPoint and toPoint are used as guides for arc creation but starting or ending points for subsequent path creation. I'll have to think about this one and post more later.