Entering “ae” in EditText becomes æ automatically

I just inherited some android code, and one of the first errors I came across was the weird EditText problem, which when I type the letters "a" and "e" in series, EditText automatically merges them into the character "æ", Full declaration xml below:

<EditText android:id="@+id/editFirstname" android:layout_width="fill_parent" android:layout_height="wrap_content" android:background="@drawable/profile_edittext_selector" android:ems="10" android:inputType="textCapSentences" android:paddingBottom="6dp" android:paddingLeft="15dp" android:paddingRight="5dp" android:paddingTop="5dp" android:textColor="#666666" android:textColorHint="#666666" android:textSize="12sp" > </EditText> 

I searched for the corresponding Activity and Fragment using xml, but I did not find anything to blame - there is no TextWatcher and no procedure trying to change the input or charsequence inside the EditText. The input language is "Use by default" (set to "English-US").

It is strange that the same error is indicated in the version of the iOS application (different developers, there is also no hint as to why this is happening).

Has anyone come across this before?

edit: declared declaration, upon request:

 <?xml version="1.0" encoding="utf-8"?> <selector xmlns:android="http://schemas.android.com/apk/res/android">\ <item android:drawable="@drawable/bgd_form_selected" android:state_pressed="true"/> <item android:drawable="@drawable/bgd_form_selected" android:state_focused="true"/> <item android:drawable="@drawable/bgd_form"/> </selector> 

edit2:

Additional Information: - Occurs on all test devices: gs2, gs3, xperia z, nexus 4, ace of galaxy

  • as above: same error registered on iOS

  • : the server receives the correct input when sending values ​​(for example, "ae" will not be converted) (this will probably narrow it down to a display problem)

+6
source share
2 answers

You wrote:

Strange, the same error is indicated in the version of the iOS application (different developers, I also don’t know why this is happening).

So, I wonder if you added a buggy version of the Roboto font to the application assets. It had an incorrect ligature rule that changed "ae" to "æ":

  <Lookup index="1"> <LookupType value="4"/> <LookupFlag value="0"/> <!-- SubTableCount=1 --> <LigatureSubst index="0" Format="1"> <LigatureSet glyph="a"> <Ligature components="e" glyph="ae"/> </LigatureSet> <LigatureSet glyph="f"> <Ligature components="i" glyph="fi"/> </LigatureSet> </LigatureSubst> </Lookup> 

It has already been fixed, so your problem can be solved by updating the Roboto font in your application assets.

+4
source

I have only knowledge in ios, no cuts for Android, sorry ... But the text property that you see here is called "ligature"

From Wikipedia

In writing and printing, a typical ligature occurs where two or more graphemes or letters combine as one symbol. Ligatures usually replace consecutive characters that separate common components and are part of a more general class of glyphs called “contextual forms”, where the particular shape of the letter depends on the context, such as surrounding letters or proximity to the end of the line.

You can try a font that has no concatenated glyphs, or there may be a property that you can flip to turn off the ligature for your text view. Interesting

Also Wikipedia ..

The symbol Æ is the lowercase æ (in ancient times called æsc) when used in Danish, Norwegian or Icelandic or Old English, and not typographic ligature. This is a great letter - a vowel - and when in alphabetical order, another place is given in alphabetical order. In modern English spelling Æ is not considered an independent letter but a spelling variant, for example: "encyclopedia" versus "encyclopedia" or "encyclopedia". Æ comes from Mediæval Latin, where in some words it was an optional ligature, such as Æneas. it is still found as an option in English and French, but this trend has recently been directed to print A and E separately. [8] Similarly, Œ and œ, although usually printed as ligatures in French, are mistakenly replaced by the letters of the components if technical restrictions require it.

While this particular one is not a ligature, but a new vowel, it is still usually defined and adjusted in the ligature setting, for example, in NSAttributedString in iOs, you will influence it using the ligature attribute (the actual name of this enum I don Remind directly Now, NSAttributedString is pretty messy because it uses different attribute names, depending on whether you use it with UIKit or with CoreText.) Good luck, look at Android text documents for a ligature

+4
source

All Articles