Re: NSLayoutManager looping with custom NSTextContainer
Re: NSLayoutManager looping with custom NSTextContainer
- Subject: Re: NSLayoutManager looping with custom NSTextContainer
- From: Sergei Borodavkin <email@hidden>
- Date: Thu, 2 Jun 2005 16:14:27 +0300
Hi Jae Ho, Douglas and all good guys reading this!
Unfortunately, it will take a long time to prepare such an example of infinitive looping (it happens quite occasionally) , but here's what I figured out these days. As far as I can see, there's no way to reject the layout of the current line in the typesetter - so, when it calls its layoutParagraphAtPoint, and the proposed rect is too short (for example, the shape, around which the text should run, is almost as wide as the text container), the typesetter cannot fit any glyphs, so it messes up the layout. I think I can override NSATSTypesetter's layoutParagraphAtPoint so that it could reject the layout of the current line if there's not enough space to fit any glyphs.
Any ideas are still appreciated :) I've seen many interesting methods in Tiger docs (like beginParagraph, endParagraph, etc.), but in my Panther there's nothing interesting about it, so I have no idea how to implement this method in my superclass.
(Overriding lineFragmentRectForProposedRect: in the typesetter didn't help).
Sergei.
On May 27, 2005, at 8:35 AM, Sergei Borodavkin wrote:
In my project I've overridden NSTextContainer to provide text wrapping around miscellaneous vector shapes (such as stars, circles, rectangles, etc). As all you know, to implement this we have to write our own lineFragmentRectForProposedRect method, which wraps the text as needed.
Everything works ok, but sometimes the text system gets into some kind of an infinite loop, and it calls my lineFragmentRectForProposedRect, passing to it proposedRect, which has _the same_ origin.y at each call.
So, the key symptoms of this situation are:
1. proposedRect.origin.y has the same value at the beginning of each lineFragmentRectForProposedRect call (hundreds, thousands, millions of time). It is often 0, but I saw also 74.
2. proposedRect.size.height vary from call to call between some two values (well, I haven't seen more). I suppose that these values are heights of two consecutive line rects situated at the place where looping happens.
If you have a reproducible case of this, it would be interesting to see it. It might then be possible (a) to fix this within AppKit, and (b) to supply criteria you could use to work around it.
Douglas Davidson
Hi Sergei,
Override NSATSTypesetter and try working out your problem.
This is how I solved my text wrapping infinite LOOP problem.
You can give me more specific information if you need further assistant.
Jae Ho
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden