On Aug 16, 2011, at 1:20 PM, Ross Carter wrote: > Right. You do have to add and remove the text containers and text views as > needed. What I meant was, you shouldn't need to do anything to insure that > the text is drawn correctly in the views and flows correctly between the > containers. What you are experiencing is an anomaly. The question is not how > to make the Cocoa text system draw correctly, but rather what in this case is > causing it to get confused.
Right. > I've been using NSTextView and friends in a multi-page layout for years, and > Martin has too. I'm very curious what is causing this problem because I > haven't seen it before. Okay. As I just found out, TextEdit has the same problem as my application, and it turns out it is using almost the same code (I didn't write the original pagination code in the app). To see it for yourself: 1. Download this RTF - <http://dl.dropbox.com/u/13168713/Wrapping%20Problem.rtf> 2. Open it in TextEdit 3. Turn on wrap to page mode in the Format menu. At this point it looks like it wraps correctly, at least if your default page size is US Letter. 4. Open Page Setup 5. Change the margins by changing the paper size I changed it to a #10 envelope size, and you can see the text getting cut off at the bottom of the page views after the change. > I'm particularly curious about your saying that after you add a page, "At > that point, their frame sizes are synchronized, and the text container is set > to track the text view's width but not its height." I don't understand why > this is necessary. Aren't all text views the same size? Why do you > synchronize their frames? (Or did you mean just the tv origins?) If you > create the tv and the tc with the correct geometry, then when you add the tc > to the layout manager it should all draw correctly. I'm talking about the text view frame size and the text container frame size. They are the same. > First, beware the delegate method > -layoutManager:didCompleteLayoutForTextContainer:atEnd:. That method can fire > when layout is still underway. The only safe thing to do with that method is > add pages, as you do. It is not a good place to to remove pages. I'll keep that in mind, though the code is not removing pages at the point where the problem is occurring. > Second, messaging the text system while layout is happening can wreck layout, > and there is no way to know when layout is underway. Therefore, when sending > any message that might affect layout, wrap the call in > performSelector:withObject:after delay:. For example, to remove pages you > could subclass NSLayoutManager and override > textStorage:edited:range:changeInLength:invalidatedRange: to send something > like [someController performSelector:@selector(checkForRemovablePages:) > withObject:self afterDelay:0]. Thanks. Nick Zitzmann <http://www.chronosnet.com/> _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
