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

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Jesse Ruderman]

Attachment: testcase

###!!! ASSERTION: unexpected anchored chunk edges: 'aLeftEdge <= aRightEdge', file layout/svg/nsSVGTextFrame2.cpp, line 4586

Comment 1

[Jesse Ruderman]

Attachment: stack

Comment 2

[Cameron McCormack (:heycam)]

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.

Comment 3

[Cameron McCormack (:heycam)]

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).

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 5

[Cameron McCormack (:heycam)]

(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.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Testcase no longer asserts.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1368ccf28b77

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/1368ccf28b77