Re: Bezier Text Container
Re: Bezier Text Container
- Subject: Re: Bezier Text Container
- From: Gordon Apple <email@hidden>
- Date: Fri, 23 Feb 2007 12:25:08 -0600
> Message: 13
> Date: Thu, 22 Feb 2007 07:23:37 -0800 (PST)
> From: Erik Buck <email@hidden>
>
> Interestingly, I did not encounter the exact layout issues with multiple-fonts
> that you encountered. I wonder why ? I encountered different issues such as
> stale drawing left behind after deleting a range of text or using undo/redo.
>
I haven't encountered the redraw problems. I should point out that I'm
currently just using NSTextView's drawing method. I had beaucoup problems
of that kind when I tried to use drawGlyphsForGlyphRange, which apparently
doesn't erase first.
I wonder if maybe you just haven't present the right test case for the
multi-font multi-segment layout. I had to experiment before I found a case
where it didn't layout correctly. Here is my theory about what is
happening.
From what I can tell, although NSlayoutManager will loop until it fits
the multi-font text into a particular segment, it appears that its sole
effort to do multi-segment lines is (when it receives a non-zero
remainingRect) to not advance vertically and to use remainingRect as the
next proposedRect. Other than that, it appears brain-dead in laying out
complete multi-segment lines. I suspect that it maintains a simple array of
rectangles to draw text, without regard to the fact that some may be on the
same line, and only advances past the bottom of the last line segment when
remainingRect = NSZeroRect.
This results in the following problems when lines have font size
changes:
- It draws only using the needed height for a segment at the top of the
available segment space, resulting in the text baseline being inconsistent
across the full line.
- It apparently only uses the bottom of the text used in the last segment
(the one that returns a 0 remainingRect) to advance to the next line, which
is why it overwrites part of the next line when the last segment contains
only smaller text.
After much effort, I have decided that there is no way to fix these
problems within the text container itself. They have to be fixed in the
layout manager. What they need to do is to treat the entire line as a
whole, rather than as independent segments. That means it should at least
keep track of the tallest segment to determine correct advancement to the
next line. It also means looping back to keep a consistent baseline across
the entire line.
Another separate issue is the one I mentioned in the first post, i.e.,
that of the text container having to shift down to get past zero-width
obstacles. That should really be part of the layout manager's function.
For specific cases, where the text container knows the details of the
shape, there may be ways around these issues -- especially the line advance.
However, our container has absolutely no a priori knowledge of the shape
which it is going to handle. In fact, currently, each call to
lineFragmentRectForProposedRect is ignorant of which segment it is
processing, which is why it is not possible for the container to fix the
overwrite problem. Heck, the container doesn't even get anything from the
layout manager that would allow proper initialization of a layout pass. If
an edit causes a re-layout starting with a secondary segment, you're screwed
as far as line advancement is concerned.
Unless someone can convince me otherwise, I'm planning on submitting
this as a bug report.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden