I just made a demo project to explore what the heck values NSStringDrawing is returning:
https://github.com/kylesluder/NSStringDrawer The line fragment results seem sensible to me, and both the glyph origin and line fragment results make sense when using device metrics, but asking for the baseline-rendering-mode glyph origin with a nonzero head indent returns a rect that always lies at x=0. This runs contrary to the docs for -boundingRectWithSize:options:attributes:, which state "the rect origin returned from this method is the first glyph origin." If this were the case, constructing a text system and querying the layout manager for -locationForGlyphIndex:0 clearly shows us that we should expect a rect that is offset by the amount of the first-line head indent. I've filed rdar://problem/13091382 on this issue, but fixing it would produce a significant-enough change that I think Apple will be very hesitant to fix it. --Kyle Sluder On Thu, Jan 24, 2013, at 12:13 PM, Kyle Sluder wrote: > On Thu, Jan 24, 2013, at 11:52 AM, Kyle Sluder wrote: > > > I expect this method to tell me the size of a rectangle (e.g. a bitmap > > > context) such that if I draw my attributed string into that rectangle, it > > > will all fit. When I say "all" I mean "all", including the margins. > > > > Considering the method is named -boundingRect…, I wouldn't expect this. > > What you're looking for is the line fragment rect, and I can understand > > why you would think passing NSStringDrawingUsesLineFragmentOrigin as an > > option would yield this information. Instead, it seems to offer the > > bounding rect of the glyph range in line fragment coordinates, which I > > would surmise is more useful information in NSStringDrawing's primary > > intended use cases. > > Huh, I just tried this in python and I got results that more closely > match _your_ expectation, not _mine_: > > >>> ps = AppKit.NSMutableParagraphStyle.alloc().init() > >>> ps.setHeadIndent_(20) > >>> ps.setFirstLineHeadIndent_(30) > >>> attrs = {AppKit.NSParagraphStyleAttributeName : ps} > >>> attributedString = > >>> Foundation.NSAttributedString.alloc().initWithString_attributes_("A", > >>> attrs) > >>> attributedString.boundingRectWithSize_options_(Foundation.NSMakeSize(1000, > >>> 1000), AppKit.NSStringDrawingUsesLineFragmentOrigin) > <NSRect origin=<NSPoint x=0.0 y=0.0> size=<NSSize width=38.00390625 > height=15.0>> > > >>> attributedString.boundingRectWithSize_options_(Foundation.NSMakeSize(1000, > >>> 1000), 0) > <NSRect origin=<NSPoint x=0.0 y=-3.0> size=<NSSize width=8.00390625 > height=15.0>> > > Note that when I pass NSStringDrawingUsesLineFragmentOrigin, I get a > width of 38 points, whereas if I omit it, I get a width of 8. > > But if I then add a tailIndent of 40, my metrics don't grow at all: > > >>> ps.setTailIndent_(40) > >>> attributedString.boundingRectWithSize_options_(Foundation.NSMakeSize(1000, > >>> 1000), AppKit.NSStringDrawingUsesLineFragmentOrigin) > <NSRect origin=<NSPoint x=0.0 y=0.0> size=<NSSize width=38.00390625 > height=15.0>> > > >>> attributedString.boundingRectWithSize_options_(Foundation.NSMakeSize(1000, > >>> 1000), 0) > <NSRect origin=<NSPoint x=0.0 y=-3.0> size=<NSSize width=8.00390625 > height=15.0>> > > So my current theory is that the advancement of the glyph is taken into > account when computing the glyph's bounding box in line fragment origin > mode. But that makes me a little surprised that the x-coordinate of the > origin of the baseline-relative rect is 0 in all cases; I would expect > it to include the glyph advancement (30). > > --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
