-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IText] IText is unusable for accent based languages #2051
Comments
With american keyboard on windows everything is fine. There was a PR somewhere in wich usin onInput event was fixing everything for everyone. |
Of course is a big limitation, and will be fixed. |
@asturur Try to switch the keyboard layout to US International - PC. Then, type |
If you have any idea of how to fix it, I would be glad to provide a PR to fix it. |
@marcospassos Needs fix for copy and pasting. |
Also @taveras and @Riddlerrr please if still interested check for chinese input. |
@asturur |
i have italian and us keyboard, both works fine. could you please open the console and check what happens when you digit normal letter and accent based one? |
This is the code I used on the "Execute" tab: When I try to input text directly inside the text element, every accent show up as the letter "a". |
@asturur Thanks for the effort. Unfortunately, it's not working yet. |
@asturur, sorry for the incomplete answer above. |
the code now is messy, so do no waste time, is a proof of concept. |
@marcospassos i installed ubuntu just to test those things. Could you give more information about your test case? http://www.deltalink.it/andreab/fabric/test3.html Use this simpler test case, where there is just and itext. |
Also i add, current kitchensink on fabricjs.com does not work with stock android browser (lollipop), while this new logic takes input. |
/cc @vamo89 (original idea of using onInput as far as i remember) @alisspers @MikyKuroneko could some of you take a test on mac os setup? |
Tested this last page (http://www.deltalink.it/andreab/fabric/test3.html) on a Mac, running 10.10.2 Yosemite, using both the US International keyboard, Chinese - Traditional Keyboard, and Japanese - Hiragana keyboard. I tested this in the latest versions of Chrome, Firefox, and Safari. The related issue #1529 I would consider resolved with this change. Good work! |
I can also confirm that it's working on a Mac running Mavericks on Chrome, Firefox and Safari. Copy/paste is also working on test3.html. I used US International and Brazil ABNT2. |
@asturur now it's working! I'm using Chrome on OSX Yosemite 10.10.2 (US International keyboard). |
good. so after waiting @kangax thoughs i try to solve style related issue. |
Both working for me too. Using Ubuntu - Chrome and Ubuntu - Firefox with Brazil ABNT2 keyboard. Copy and paste working as well. Thanks @asturur. |
@asturur Are you able to publish the work you've done so far for your test pages? I would like to finish it up and pull request it. |
This demo http://www.deltalink.it/andreab/fabric/test3.html doesn't work here, my env: tried:
with
|
i overwrited the demo accidentally |
Currently, the IText input binding strategy has some issues and one of most critical one is that IText is completely unusable for accent based languages (such as Portuguese, Spanish, Japanese, Chinese, etc) due the lack of support to dead keys.
The problem
IText uses a hidden input for capturing user's input, through the
keydown
event. The problem is thatkeydown
events originated from dead keys cannot be converted into characters, because the event does not provide the character's code but a fixed key code (229) instead.Examples:
229
+
c229
,229
+
a229
,229
+
u229
,229
+
~229
,229
+
~+
~+
a229
,229
,229
,229
+
[space]229
,229
Notice that pressing
a
after a dead key produces another dead key event. So, it's very hard to handle it in the way it's currently architected.Holding the key of a given character to choose one of its variants is OS specific and almost no user of accented keyboards is familiar with this, so it's not a good alternative IMHO. I've been trying to fix it in the last days, but seems like we should change the way it is currently done, once we'll have to reimplement basic browsers/OS features bringing a lot of unnecessary code overhead.
Unfortunately, we've been working on a big startup project in the last months without noticing this issue and maybe we'll have to stop it immediately, at least until discover a workaround.
Related issues: #1175 and #1954
The text was updated successfully, but these errors were encountered: