• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];


  • Subject: Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
  • From: Robert Clair <email@hidden>
  • Date: Sat, 22 May 2004 11:20:25 -0400

Well, you should not have to start the process somewhere. A closed path is the same wherever you start drawing it. When you draw a circle, you don't have to choose a 'start' point, do you? What is the problem with taking the last point in the path as the point from which the first line is drawn?

As a practical matter, a human being drawing a circle (or a computer stroking an
[ approximately :-) ] circular path) most certainly does: you have to put the pen down
_somewhere_ when you begin.


it seemed as though you were referring to "paths with only line elements in them" as "open polylines". In answer to your question, I can assume that paths with only line elements in them are implicitly closed because, as you note, open polylines are not paths with only line elements in them. They also have a point element in them.


I think I begin to see the problem: you are attached to certain (pedantic in my view) ideals
of notational purity. When I was a physicist, I was an experimentalist not a theorist and the attitude caries
over into software engineering: I am much more interested in making interesting stuff that works than
in discussions of notation or representation. I am not bothered by the moveTo among the lineTo's - I'm
just happy that it draws the path I asked for.

As for breaking things, consider carefully _all_ the implications of what you ask for. The additional functionality
won't immediately break my program, but what if someone uses the new stuff to create some of these beasties
and then somehow gets one of them into a file that is read into my program ? The non-standard creature will absolutely break much of the 1700 lines of code in my NSBezier category and I will have to go an
rewrite them to test for the variant and then behave differently. (I'm not really worried about this, I think
the chances that Apple would take you up on the suggestion are fairly small and the chances that
Adobe would modify pdf and PostScript in the same way to be less than nil.)


If you are going to wish for Apple to expend resources on NSBezierPath, there are a host of more
useful things to ask for: easier editing of the path segments, something that returns info about
the interior control points on either side of a control point on the path (if you are moving the
point on the path in many cases you want to move all three so the join angle or tangency is preserved),
approximate offset of path, project a point on a path, split path at point, etc, etc

(Yes I know you can write your own. I have, but it would be easier if they were there already.)


.....Bob Clair
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
      • From: Hamish Allan <email@hidden>
References: 
 >Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]]; (From: Hamish Allan <email@hidden>)

  • Prev by Date: Re: Menu-less popup buttons
  • Next by Date: Re: Variable argument lists
  • Previous by thread: Re: {Spam?} Re: [firstPath appendBezierPath: [secondPathbezierPathByReversingPath]];
  • Next by thread: Re: [firstPath appendBezierPath: [secondPath bezierPathByReversingPath]];
  • Index(es):
    • Date
    • Thread