[Drawkit] changing font

[James Maxwell]

Just a note, Graham, that -adoptPath: is working beautifully. Much  
simpler!
The only little hitch was having to add an extra line to set up valid  
bounds for my object (I used a rectOfUnitSize), in order to avoid the  
"divide by zero" error.

thanks.

J.


On 26-Jun-08, at 6:52 PM, Graham Cox wrote:

>
> On 27 Jun 2008, at 11:28 am, James Maxwell wrote:
>
>> Okay, I don't see +drawableShapeWithBezierPath: but there is  
>> +drawableShapeWithPath:, which I'm assuming is what you mean. I'll  
>> give that a try later. I was basically hand-building my path from  
>> the glyph, using -appendBezierPathWithGlyph:, then using -setPath:  
>> from DK, but as I say, that leaves me to mess around with the  
>> bounds... I'll try the convenience method a little later.
>
>
> Yes, it's + drawableShapeWithPath: in beta 3, the name got/will be  
> changed ;-)
>
> using setPath: will be a pain in the neck, as you have found. I'll  
> explain why, for the benefit of the list.
>
> Shapes store their paths bounded by a square 1.0 units on each side,  
> centred at the origin (i.e. they extend from -0.5 to +0.5 in each  
> dimension). The path is then transformed to the real size, position  
> and angle on the screen. The -setPath: method expects a path in this  
> form, what I call a "canonical path". If it's not, you'll get  
> incorrect results. In fact the latest code doesn't even let you pass  
> an arbitrary path, it will assert if the bounds is non-canonical.  
> The use of a canonical path makes the various transforms to and from  
> the screen much easier to handle.
>
> That isn't terribly convenient in many cases, so there is another  
> method -adoptPath: which works with any path. It inversely  
> transforms the path into canonical form for storage. So by passing  
> your glyph path to adoptPath: you should eliminate all the mucking  
> about needed to "fit" the glyph to the bounds. The convenience  
> constructor does the same.
>
> By the way I know the dearth of documentation isn't helping, but the  
> comment headers for these methods does actually explain this. FWIW,  
> if you use a method, you should probably read any notes for it in  
> the code just in case there's something unexpected hidden there, as  
> there is in this case. While I try to name things as well as I can,  
> sometimes assuming behaviour from the name alone is going to get you  
> into trouble. This is also why names get changed, which is in itself  
> often a pain in the neck, I know.
>
>
> cheers, Graham
> _______________________________________________
> Drawkit mailing list
> Drawkit at lists.apptree.net
> http://lists.apptree.net/listinfo.cgi/drawkit-apptree.net