> The documentation is a a bit ambiguous: it doesn't tell you in which > coordinate system it applies. The upper left corner in a flipped view is > arguably the lower left corner as seen on the screen. I haven't looked
Yes, its not very clear is it ? I think it is designed to work as a PSmoveto() and PSshow() do though - in which the specified point becomes the bottom left corner of the *text* as seen on screen. Flipped it becomes top left for some reason - but GNUstep appears to get that right anyway. It also gets the drawInRect correct, so the only incorrect behaviour was a simple drawAtPoint: in a non flipped view, which I would have thought was the most common case, but maybe not :-) > closely at it, but if the new behavior matches OPENSTEP, it's probably > better to just stick to that (and document it in a clear way :). Its now matches OSX and OpenStep pretty closely - GNUstep text isnt quite positioned the same as OSX text, but I think that might be due to differing fonts. The drawInRect: behaviour is the same as OSX's. Interestingly OSX doesnt match OpenStep in this area (and neither match the documentation!) but the differences only become apparent if you draw text into a rectangle much too large for it. I think this is a rare case, and I also think that if we have to choose between macthing OpenStep or OSX we should choose OSX really. > I'll commit something similar to this tomorrow after fixing any > incorrect callers in -gui (or have you already looked at them?). I did a quick grep for drawAtPoint in gui/Source and it only seems to be used by NSTabViewItem and NSRulerView - neither of which I had test code for, so I havent looked to see if they need fixing, plus it was late last night and I didnt have time. I suspect they do as even in the grep output I can see a suspicious looking NSMaxY in the TabView call. cheers, -bat. _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
