What steps will reproduce the problem? 1. Add phrase for shrugie as per Atlantic article http://www.theatlantic.com/technology/archive/2014/05/the-best-way-to-type-__/371351/
The trigger phrase is &shrug; This produces immediate results close to the required value. I get results with the central katakana character missing, even though the font in use has that character.
The Atlantic is widely read and you may be getting more about the shrugie.
What is the expected output? ¯_(ツ)/¯ What do you see instead? ¯_()/¯
What version of the product are you using? On what operating system?
Autokey-gtk 0.90.4
Description: Ubuntu 14.04 LTS Codename: trusty Linux sda8 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 GNU/Linux jessie/sid
Please provide any additional information below. I'm guessing that Autokey doesn't handle Unicode properly. The Unicode character in question is Katakana letter tu: U+30C4 Directly entering the shrugie or the katakan tu by works. In terminal the ctrl-shift-u 30c4 works directly. But the Autokey shrugie does not.
My software (editor and terminal I'm using to test Autokey) is all set to utf8. Is that what Autokey uses?
- Autokey.log 198.98KB
- AutokeyError.txt 358
Comment #1
Posted on Feb 1, 2015 by Happy GiraffeHi, i found a simple workaround this problem :)
- thejake.py 155
Status: New
Labels:
Type-Defect
Priority-Medium