Line fragments and baseline
Line fragments and baseline
- Subject: Line fragments and baseline
- From: Michael Monscheuer <email@hidden>
- Date: Mon, 19 Jun 2006 10:31:41 +0200
Hi!
I managed to let text flow around objects by subclassing NSTextContainer (overriding
lineFragmentRect:forProposedRect:sweepDirection:movementDirection:remainingRect:).
Playing around with it I encountered a problem with multiple text stylings applied to a text line that
gets fragmented:
For example: If text line is fragmented into two parts (one resulting fragment left of flow around
object and another fragment right of flow around object) and left fragments contains 12pt
text while right fragment contains some glphs in 12pt and some in 20pt, resulting line fragments do
not match in height and baseline.
The result is a left fragment of 14pt in height and a right fragment of 24pt in height.
That causes unwanted optical effect as baselines of both fragments do not align to same y position.
Now one could propose to change line fragments after paragraph formatting is done (or tracking text line
formatting myself and adjust line fragments at end of text line layout process).
But this would end up in unwanted results as well: As fragments are served by text container which
encloses flow around analysis, tweaking line fragments after formatting would not take flow around
desires into account (it causes line fragments overlapping objects text should flow around).
So how can I get baselines of line fragments be aligned to identical y position?
Some Notes:
Simple case, one fragment per text line:
Typesetters' layoutParagraphAtPoint: in fact calls its getLineFragment methods twice with different
stylings found applied to characters to be layouted:
First it gets line fragment with a proposed rect that is calculated based on styling at
first glyph to lay out.
I think this possibly makes it easier for typesetter to limit glyph range to be analysed.
Using the result of first call, getLineFragment method is called again with a proposed
height summed up by taking all encountered style changes into account.
Fragmented case, two fragments per text line:
First typesetter gets first line fragment with a proposed rect that is calculated based on styling at
first glyph to lay out. The resulting fragment limits style analysis too and for that no second call
of getLineFragment occurs as no style changes are located in first fragment.
Now typesetter gets second fragment. If second fragment contains style changes typesetter calls
getLineFragment twice (like in my simple case above).
The result is two line fragments with different stylings and for that possibly different
baseline locations.
Addendum: Line fragment rect implementation is quite flexible. But this flexibility seems to make
it hard to implement standard cases (like text line splitted into fragments) with correct optical
results (And there are more mad cases about formatting than described here, but most of them
can be solved by extra code).
Thank you for reading,
Michael Monscheuer
_______________________________________________
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