Jesse Ruderman Reporter
	Description • 17 years ago

The testcase triggers:

###!!! ASSERTION: Break suggested inside cluster!: '!aBreakBefore[i] || mCharacterGlyphs[aStart + i].IsClusterStart()', gfxFont.cpp, line 700

###!!! ASSERTION: BreakAndMeasureText called, not ending at cluster boundary: 'aStart + aMaxLength == mCharacterCount || charGlyphs[aStart + aMaxLength].IsClusterStart()', gfxFont.cpp, line 1209

###!!! ASSERTION: Ended in the middle of a cluster...: '*aEnd == mCharacterCount || charGlyphs[*aEnd].IsClusterStart()', gfxFont.cpp, line 860

etc.

	Jesse Ruderman Reporter
	Comment 1 • 17 years ago

Bug 385289 triggers a lot of the same assertions.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 2 • 17 years ago

There are really two bugs here. The first bug is "Break suggested inside cluster!", which is caused by the nsILineBreaker implementation telling us we can break between the minus and the ZWJ. I guess I can fix that directly.

The second bug is caused by text nodes spanning cluster boundaries: we end up trying to paint the text frame and paint characters that are part of a whole cluster. We don't plan to support this, but I guess we still need to figure out how to handle it without asserting. Perhaps the best way is to change nsTextFrameThebes to advance its start and end offsets forward to the nearest cluster boundary when measuring and/or drawing? This effectively means that a cluster is associated with the frame of its first character. How does that sound?

	Simon Montagu :smontagu
	Comment 3 • 17 years ago

That sounds like the Right Thing To Do to me.

On a slight tangent: we should probably state clearly somewhere that by design we don't support style changes in mid-cluster, because it's something that people sometimes want (especially colour changes) and expect to be able to achieve in HTML.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 4 • 17 years ago

> because it's something that people sometimes want (especially colour changes)
> and expect to be able to achieve in HTML.

Mid-cluster, really? Style changes mid-ligature or between shaped glyphs, sure. But we frequently don't get enough information from the platform APIs to know which glyphs correspond to which characters in a cluster.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 5 • 17 years ago

Actually I think the best approach here is to do the text offset adjustements in gfxTextRun. Simpler and more robust that way.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 6 • 17 years ago

This mostly removes any requirements that gfxTextRun API text subranges be aligned to cluster boundaries. As the comment says, we now draw/measure the glyphs for a cluster if the cluster's first character is in the subrange. The hard part of this is getting partial ligature handling right; to get that right I had to rework partial ligature handling. In doing so I fixed a bug where we might ask an aProvider for spacing data for a whole ligature, when part of the ligature falls outside the range of the text handled by the aProvider. This could be very bad.

The break-related assertion in this bug is fixed by changing gfxTextRun::SetPotentialLineBreaks so that instead of asserting when a line break opportunity is recorded inside a cluster, we merely warn and drop the break opportunity.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 8 • 17 years ago

checked in.

	Jesse Ruderman Reporter
	Comment 9 • 17 years ago

Crashtest checked in.