614468 - gfxPlatform::SetupClusterBoundaries should treat halfwidth Katakana sound marks as extending a cluster

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Karl Tomlinson (:karlt)]

U+FF84 HALFWIDTH KATAKANA VOICED SOUND MARK and
U+FF9E HALFWIDTH KATAKANA SEMI-VOICED SOUND MARK are listed in
http://www.unicode.org/Public/6.0.0/ucd/auxiliary/GraphemeBreakProperty.txt
with property Extend, and so should join the cluster of the previous
character.
http://www.unicode.org/reports/tr29/tr29-17.html#Default_Grapheme_Cluster_Table

(The normal width Katakana-Hiragana sound marks have independent combining and
non-combining forms U+3029 - U+309C.)

pango_break handles this
(http://git.gnome.org/browse/pango/tree/pango/break.c?id=1.28.3#n685) so this
would be a regression if switching away from pango_break in bug 569770.

Comment 1

[Karl Tomlinson (:karlt)]

Attachment: testcase

The two characters in the text input should appear as one grapheme cluster.
i.e. the caret should move across both characters and mouse/cursor-key selection should always select both characters (or neither).

Comment 2

[Alex Miller]

(In reply to comment #1)
> Created attachment 492899 [details]
> testcase
> 
> The two characters in the text input should appear as one grapheme cluster.
> i.e. the caret should move across both characters and mouse/cursor-key
> selection should always select both characters (or neither).

Couldn't reproduce on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12 .

It appeared as a single cluster.

Comment 3

[Karl Tomlinson (:karlt)]

Yes, currently this only behaves as expected on Linux, because the code there does not (yet) depend on gfxPlatform::SetupClusterBoundaries

http://hg.mozilla.org/mozilla-central/rev/709c439bd66f

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: patch

I wrote this then saw Jonathan's patch http://hg.mozilla.org/try/rev/23403c3f75a1 which covers some of the more complex issues mentioned in bug 614476.

Jonathan: where are you at with that patch?  Does it have a bug?
Is it likely to land soon?
If so the change here would be better done on top of that patch.

Comment 5

[Jonathan Kew [:jfkthame]]

(In reply to comment #4)
> Created attachment 493895 [details] [diff] [review]
> patch
> 
> I wrote this then saw Jonathan's patch
> http://hg.mozilla.org/try/rev/23403c3f75a1 which covers some of the more
> complex issues mentioned in bug 614476.
> 
> Jonathan: where are you at with that patch?  Does it have a bug?

I was initially going to fix this bug, then noticed bug 553981 as well and so wrote that patch with the intention of fixing both of them - I was going to post the patch there, as that's by far the bigger part of it.

> Is it likely to land soon?

Once I've looked at the tryserver oranges and fixed whatever's wrong there, I was going to flag you for review - within a day or so, I hope, if not too many distractions pop up.

> If so the change here would be better done on top of that patch.

(That patch includes this change anyway.)

Comment 6

[Karl Tomlinson (:karlt)]

Comment on attachment 493895 [details] [diff] [review]
patch

(In reply to comment #5)
> (That patch includes this change anyway.)

Oh, missed that the first time I looked.
Your patch looks much better then.

Comment 7

[Jonathan Kew [:jfkthame]]

See https://bugzilla.mozilla.org/attachment.cgi?id=495020 in bug 553981.

Comment 8

[Jonathan Kew [:jfkthame]]

This was fixed by the patch in bug 553981.