Closed Bug 614468 Opened 9 years ago Closed 9 years ago

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

Categories

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

x86_64
All
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: karlt, Assigned: jfkthame)

References

Details

Attachments

(2 files)

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.
Attached file 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).
Assignee: nobody → karlt
Blocks: 614476
Blocks: 329069
(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.
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
Flags: in-testsuite+
OS: Linux → All
Blocks: 615445
Attached patch patchSplinter Review
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.
Attachment #493895 - Flags: review?(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 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.
Attachment #493895 - Flags: review?(jfkthame)
Assignee: karlt → jfkthame
Depends on: 553981
This was fixed by the patch in bug 553981.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.