Issue 710899 has been merged into this issue.

Note that it's not the keyboard layout that determines the combinations (e.g. Dead<'> + s ↦ ś), it's character composition, which is layout-independent.

I'm thinking a way to let InputMethodChromeOS to pass some parameters to CharacterComposer according to the accent option.

Kevin, do you think it is a feasible solution?

Btw, it is easy to implement an extension based keyboard (not XKB based) for the new Windows-like US International keyboard. However, it might be tricky to enable it at login screen.

#3 I was thinking along those lines overnight but am temporarily very busy and haven't had time to check into it yet. (I did work on the composer table when we removed GTK a couple years ago, but my memory is not fresh.) It seems reasonable that we could have some flags determined by the current keyboard layout that control which parts of the composition tree apply.

Team - any news here? Brazil office is pushing chrome adoption and this is critical feature to have success here. The experience with current keyboard is not good.

I've looked into #3/#7 in my copious free time, and selecting parts of the composition tree according to some layout-dependent flags would handle part of the problem, namely distinctions like Windows-style Dead<combining_acute>+c↦ç vs regular Dead<combining_acute>+c↦ć.

However there is another part of the problem: On Windows, when there is no composition match, the result is multiple independent characters with the dead key replaced by a printable key, e.g. <combining_acute> ↦ <'>, which, note, is an apostrophe *not* an acute <´>. We don't currently have a mechanism for that kind of fallback mapping.

https://support.microsoft.com/en-us/help/306560/how-to-use-the-united-states-international-keyboard-layout-in-windows-7,-in-windows-vista,-and-in-windows-xp
http://sites.psu.edu/symbolcodes/windows/codeint/

Kevin, do you think it would be easier to just implement a new XKB symbol?

Sorry, I was wrong. We have to change the CharacterComposer logic.

Kevin, mind taking this to make CharacterComposer to support override new character composer sequences, which the client code can create at runtime?

I'm thinking to do as:
1) make a new character_composer_sequences_us_intl.txt
2) use generate_character_composer_data.py to compile to get character_composer_data_us_intl.h
3) make a new input method "xkb:us:intl-pc:eng", and once it's activated, merge/override character_composer_data_us_intl to character_composer_data.
4) And once it's deactivated, un-merge it.

WDYT?

#13 I started looking at this. What I am thinking now is to add selection flags to each node in the composition tree (i.e. character_composer_data). The leaves would be flagged with PC_INTL (for example Dead<acute> + <c> ↦ <ç>) or NOT_PC_INTL (for example Dead<acute> +
 <c> ↦ <ć> and Dead<acute> + <s> ↦ <ś> and so on) or ALL (most non-accent things). The intermediate nodes would have the union of the flags below, so we don't search subtrees unnecessarily. (I should make a doc for this because a diagram would explain better.)

So the input method would pass the flag PC_INTL for the Windows-style layout and CharacterComposer would default to NOT_PC_INTL for everything else.

I'm still thinking about the failed-composition problem (e.g. Dead<acute> + <s> ↦ <'> + <s> in the Windows style). This could actually be useful for non-Windows-style layouts as well. For a non-Windows example, there is no composition for Dead<circumflex>+<q> because there is no Unicode character precomposed <q̂>, but composition could fall back to returning <q>+<combining_circumflex>.

Anyway, I will move ahead with the character_composer_data part. I'm not on Chrome team now so it will be best-effort, but it looks like it shouldn't be too much work.

#11 Actually that could work, and might be simpler than having different composer data (sub)trees. The only awkward part is that the xkeyboard-config ebuild would have to change.

We would define some additional constants to use as xkeysyms and create an xkb layout (e.g. 'us:intl_pc') that is similar to 'us:intl', except that instead of xkeysyms dead_acute, dead_tilde, etc. it would have (for example) U80000027, U8000007E, etc. Then map those to DomKey::Dead<'>, DomKey::Dead<~>, etc. instead of DomKey::Dead<combining_acute_accent> that regular layouts use. That is, we would a have different set of Dead<> keys for Windows-style, and only add the vowel combinations to character_composer_sequences.txt.

Then the composition failure case could be handled like this: if the encoded dead key is printable, the output is that character *before* the other, and if it's a Unicode combining character, the output is that character *after* the others (because Unicode combining accents are postfix). For example, for a regular layout,
  Dead<combining_circumflex> + <q> → no match → <q> + <combining_circumflex> = q̂
but for a Windows-style layout,
  Dead<^> + <q> → no match → <^> + <q> = ^q

Looks good for #15!

Kevin, any updates for this?

Only had time for a bit of work, but I've confirmed that XKB can handle the #11 approach. The ‘custom keysyms’ need to be written as a numeric constant and need to not have bit 31 set (I guess there's a sign/range check somewhere). So, not (for example) U80000027 as I guessed in #15, but 0x40000027. I've prepared a 'us:intl_pc' that matches the PC one as far as I can tell.

My next steps will be to handle these in the //ui/events, and add the combinations to character_composer_sequences.txt. Those will be easy and just need a bit of time to get all the new keys into the various tables. After that, the fallback case in CharacterComposer to make (e.g.) <'>+<s>→<'s> instead of discarded — I haven't looked at that at all yet.

There are some steps that it would be better for you and your team to do, like actually adding the 'us:intl_pc' layout to the system with suitable localized names (especially pt_BR). I guess there might be some debate about naming this vs the existing 'us:intl', which could get started already.

The Eng effort of adding the entry for us:intl_pc is trivial.
However, adding the on-screen keyboard support for us:intl_pc requires significant amount of effort.
I will firstly consider adding the on-screen keyboard for it in the extension.

Meanwhile, abodenha@, could you suggest a name for the new keyboard? Thanks.

I have a working prototype with Windows-style combinations suitable for pt_BR, e.g. <'>+<e>↦<é>, <'>+<c>↦<ç>, <'>+<s>↦<'s>, using the private-keysym method.

Yingbing, can you please help to consider the on-screen keyboard support for these behaviors? Thanks!
https://support.microsoft.com/en-us/help/306560/how-to-use-the-united-states-international-keyboard-layout-in-windows-7,-in-windows-vista,-and-in-windows-xp
http://sites.psu.edu/symbolcodes/windows/codeint/

I will put the "onscreen keyboard support" task on my schedule. 

Hi Everyone,
Do we add new xkb IME or just change the current "xkb:us:intl:eng" IME behavior?

If we decide to add the new one, how about name it as "xkb:us:intl_pc:eng"?

I already implements the behavior on-screen keyboard, and use "xkb:us:intl_pc:eng" as name temporarily. 

Any question please reply as soon as possible.

#23, OK, I will submit the new XKB layout as us:intl_pc. I've used https://en.wikipedia.org/wiki/File:KB_US-International.svg as the reference for defining it.

lgtm for "xkb:us:intl_pc:eng".
However, we still need a label name for the new keyboard.
I would say "US International (PC)". Any ideas?

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/chromeos-overlay/+/b0f2a76f8f350f9b28c13df66ed03c46d1382703

commit b0f2a76f8f350f9b28c13df66ed03c46d1382703
Author: Yingbing Wu <wuyingbing@google.com>
Date: Sat Jun 17 08:12:43 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/chromeos-overlay/+/64c15a7f8fee89afc506f9a0a458bc13be01cc23

commit 64c15a7f8fee89afc506f9a0a458bc13be01cc23
Author: Yingbing Wu <wuyingbing@google.com>
Date: Mon Jun 26 05:29:17 2017

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/chromeos-overlay/+/64c15a7f8fee89afc506f9a0a458bc13be01cc23

commit 64c15a7f8fee89afc506f9a0a458bc13be01cc23
Author: Yingbing Wu <wuyingbing@google.com>
Date: Mon Jun 26 05:29:17 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d95e4951a3bab57b4839e3a3d7e64d43c8079d42

commit d95e4951a3bab57b4839e3a3d7e64d43c8079d42
Author: wuyingbing <wuyingbing@chromium.org>
Date: Wed Jun 28 06:15:16 2017

Adds US International (PC) keyboard title message item.

BUG= 718368 

Review-Url: https://codereview.chromium.org/2950243002
Cr-Commit-Position: refs/heads/master@{#482902}

[modify] https://crrev.com/d95e4951a3bab57b4839e3a3d7e64d43c8079d42/ui/base/ime/chromeos/input_method_util.cc
[modify] https://crrev.com/d95e4951a3bab57b4839e3a3d7e64d43c8079d42/ui/chromeos/ui_chromeos_strings.grd

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/45abfe24b9fb22f2ca0bcc99c8d45fb5f4df003f

commit 45abfe24b9fb22f2ca0bcc99c8d45fb5f4df003f
Author: wuyingbing <wuyingbing@chromium.org>
Date: Mon Jul 03 02:26:53 2017

Adds us(intl_pc) IME to xkb extension.

BUG= 718368 

Review-Url: https://codereview.chromium.org/2942423002
Cr-Commit-Position: refs/heads/master@{#483927}

[modify] https://crrev.com/45abfe24b9fb22f2ca0bcc99c8d45fb5f4df003f/chrome/browser/resources/chromeos/input_method/google_xkb_manifest.json

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e07b808219d45503263f39cee9c2f8f7bd316edd

commit e07b808219d45503263f39cee9c2f8f7bd316edd
Author: Kevin Schoedel <kpschoedel@google.com>
Date: Tue Jul 04 15:43:03 2017

Support Windows-style dead key composition.

This CL makes it possible to create an XKB layout that mimics
the behaviour of Windows' "US International".

1. Interpret particular non-standard XKB keysyms as dead keys.

2. Add a second class of dead key combining sequences, using
   encoded printable characters rather than combining characters,
   and limited to the specific sequences handled by Windows'
   "US International" layout.

3. Handle failed compositions for these dead keys by returning
   the corresponding printable character followed by the current
   key.

Bug:  718368 
Change-Id: I5bbbf5ee4697db2954f3057be6eeabc7b898bb41
Reviewed-on: https://chromium-review.googlesource.com/538920
Reviewed-by: Gary Kacmarcik <garykac@chromium.org>
Reviewed-by: Shu Chen <shuchen@chromium.org>
Commit-Queue: Kevin Schoedel <kpschoedel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#484113}
[modify] https://crrev.com/e07b808219d45503263f39cee9c2f8f7bd316edd/ui/base/ime/chromeos/character_composer.cc
[modify] https://crrev.com/e07b808219d45503263f39cee9c2f8f7bd316edd/ui/base/ime/chromeos/character_composer_data.h
[modify] https://crrev.com/e07b808219d45503263f39cee9c2f8f7bd316edd/ui/base/ime/chromeos/character_composer_sequences.txt
[modify] https://crrev.com/e07b808219d45503263f39cee9c2f8f7bd316edd/ui/base/ime/chromeos/character_composer_unittest.cc
[modify] https://crrev.com/e07b808219d45503263f39cee9c2f8f7bd316edd/ui/events/keycodes/keyboard_code_conversion_xkb.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/0dcf90de00372d867cbe7cc36c8ffd5653141dda

commit 0dcf90de00372d867cbe7cc36c8ffd5653141dda
Author: Kevin Schoedel <kpschoedel@chromium.org>
Date: Tue Aug 01 20:01:39 2017

Add us(intl_pc) layout.

This layout works like MS Windows' US International,
which is different from the normal XKB us(intl).
The layout requires specific support from Chromium's
key handling and character composition  see
https://chromium-review.googlesource.com/c/538920

BUG= chromium:718368 
TEST=manually on link

Change-Id: I06b44d077000c3cb85a4ef7108f56bbe857bb40c
Reviewed-on: https://chromium-review.googlesource.com/538914
Commit-Ready: Kevin Schoedel <kpschoedel@chromium.org>
Tested-by: Kevin Schoedel <kpschoedel@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Shu Chen <shuchen@chromium.org>
Reviewed-by: Yingbing Wu <wuyingbing@google.com>

[rename] https://crrev.com/0dcf90de00372d867cbe7cc36c8ffd5653141dda/x11-misc/xkeyboard-config/xkeyboard-config-2.15-r3.ebuild
[modify] https://crrev.com/0dcf90de00372d867cbe7cc36c8ffd5653141dda/x11-misc/xkeyboard-config/xkeyboard-config-2.15.ebuild
[add] https://crrev.com/0dcf90de00372d867cbe7cc36c8ffd5653141dda/x11-misc/xkeyboard-config/files/xkeyboard-config-2.15-us-intl-pc.patch

We use Chrome books in our university for Examination purpose we determined that Google US INTL keyboard layout is not standard. The Google US INTL layout gives totally different character. By using combination Shift + 6 you get ² instead of ^. Please fix it ASAP.

Shashi

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/a2594cda1b0f709cec3db00dcbe4d62f2b169b8e

commit a2594cda1b0f709cec3db00dcbe4d62f2b169b8e
Author: Kevin Schoedel <kpschoedel@chromium.org>
Date: Wed Aug 23 06:12:34 2017

Add us(intl_pc) layout.

This layout works like MS Windows' US International,
which is different from the normal XKB us(intl).
The layout requires specific support from Chromium's
key handling and character composition  see
https://chromium-review.googlesource.com/c/538920

BUG= chromium:718368 , chromium:749350 
TEST=manually on link

Change-Id: I06b44d077000c3cb85a4ef7108f56bbe857bb40c
Reviewed-on: https://chromium-review.googlesource.com/538914
Commit-Ready: Kevin Schoedel <kpschoedel@chromium.org>
Tested-by: Kevin Schoedel <kpschoedel@chromium.org>
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
Reviewed-by: Shu Chen <shuchen@chromium.org>
Reviewed-by: Yingbing Wu <wuyingbing@google.com>
(cherry picked from commit 0dcf90de00372d867cbe7cc36c8ffd5653141dda)
Reviewed-on: https://chromium-review.googlesource.com/623627
Tested-by: Yingbing Wu <wuyingbing@chromium.org>
Reviewed-by: Keigo Oka <oka@chromium.org>
Reviewed-by: Yingbing Wu <wuyingbing@chromium.org>
Commit-Queue: Yingbing Wu <wuyingbing@chromium.org>

[rename] https://crrev.com/a2594cda1b0f709cec3db00dcbe4d62f2b169b8e/x11-misc/xkeyboard-config/xkeyboard-config-2.15-r3.ebuild
[modify] https://crrev.com/a2594cda1b0f709cec3db00dcbe4d62f2b169b8e/x11-misc/xkeyboard-config/xkeyboard-config-2.15.ebuild
[add] https://crrev.com/a2594cda1b0f709cec3db00dcbe4d62f2b169b8e/x11-misc/xkeyboard-config/files/xkeyboard-config-2.15-us-intl-pc.patch

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f30964a1984f9334d2f2d16af3c22956856125a7

commit f30964a1984f9334d2f2d16af3c22956856125a7
Author: Kevin Schoedel <kpschoedel@chromium.org>
Date: Fri Mar 02 03:35:29 2018

Add missing mappings for Windows-style keyboard layout.

Mappings for `a and ~a were not listed in the reference used for
the "US International (PC)" layout, but are active and important
for Brazilian Portuguese users.

Bug:  718368 
Change-Id: I1e8e05f9fa90296cfa171d2003ca77829baf4886
Reviewed-on: https://chromium-review.googlesource.com/944187
Reviewed-by: Shu Chen <shuchen@chromium.org>
Commit-Queue: Kevin Schoedel <kpschoedel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540437}
[modify] https://crrev.com/f30964a1984f9334d2f2d16af3c22956856125a7/ui/base/ime/chromeos/character_composer_data.h
[modify] https://crrev.com/f30964a1984f9334d2f2d16af3c22956856125a7/ui/base/ime/chromeos/character_composer_sequences.txt

I think this feature has been done.