Closed Bug 950324 Opened 6 years ago Closed 4 years ago

"ASSERTION: unexpected anchored chunk edges" with combining accent in SVG

Categories

(Core :: SVG, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jruderman, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, testcase)

Attachments

(2 files)

Attached image testcase
###!!! ASSERTION: unexpected anchored chunk edges: 'aLeftEdge <= aRightEdge', file layout/svg/nsSVGTextFrame2.cpp, line 4586
Attached file stack
The problem seems to be that nsTextFrame reports the space character as being trimmed, even though it is the first character of a cluster once it is combined with the U+0301.  This results in the character not being "addressable" by SVG positioning attributes, which means it's inelgible to be the start of the anchored chunk.  From there, the anchoring measurements go wrong.
roc, can you say whether with the attachment it makes sense that the nsTextFrame will return (1,1) as the trimmed offsets (i.e., it'll trim the space) while the text run will report that the U+0301 character is not a cluster start?  I wonder whether it makes more sense to have the nsTextFrame not trim the space or to make nsSVGTextFrame2 work around that in its CharIterator (which is going to be a bit awkward, but doable).
Flags: needinfo?(roc)
I think it would be logical to treat this space is not collapsible. Arguably that's incompatible with the wording of CSS3 Text: http://dev.w3.org/csswg/css-text-3/#collapsible
What do other browsers do?

(In reply to Cameron McCormack (:heycam) from comment #3)
> I wonder whether it makes more sense to have the nsTextFrame
> not trim the space or to make nsSVGTextFrame2 work around that in its
> CharIterator (which is going to be a bit awkward, but doable).

Where you check for clusters, perhaps you could just extend the check to always regard the first character as the start of a cluster regardless of what the textrun says.
Flags: needinfo?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4)
> I think it would be logical to treat this space is not collapsible. Arguably
> that's incompatible with the wording of CSS3 Text:
> http://dev.w3.org/csswg/css-text-3/#collapsible
> What do other browsers do?

It's hard to tell, as it's hard to see what the difference between U+0020 U+0301 and a lone U+0301 is (or even should be) so I don't know if they are trimming.

> (In reply to Cameron McCormack (:heycam) from comment #3)
> > I wonder whether it makes more sense to have the nsTextFrame
> > not trim the space or to make nsSVGTextFrame2 work around that in its
> > CharIterator (which is going to be a bit awkward, but doable).
> 
> Where you check for clusters, perhaps you could just extend the check to
> always regard the first character as the start of a cluster regardless of
> what the textrun says.

Yeah, that might work; I'll try.
Testcase no longer asserts.
Status: NEW → RESOLVED
Closed: 4 years ago
Flags: in-testsuite+
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.