Alternative Encoders Tutorial

This tutorial describes how to use the alternative character encoders.

Introduction

Alternative Encoders support many Latin-based Eastern European characters. Default 7 bit encoders do not support Latin-based characters. The characters must be encoded using 16-bit Unicode. The use of Unicode limits the users to 70 characters in a single message. The Alternative Encoders supports the use a lossy conversion and can change the Eastern European characters to the nearest Global System for Mobile communication (GSM) character. The character converters are plug-ins to the SMS stack. The Alternative Encoders are optional and can be included in the ROM build time.

When the user writes an SMS message data the SMS stack checks the characters and finds the encoders available. If installed, the SMS stack uses the Alternative Encoder. If the Alternative Encoders are not installed the default encoder available is used. The 7-bit default converter converts the unsupported characters to '?' and the alternative encoders changes them to closest GSM supported character.

The client applications can call the CSmsMessage::IsSupportedL() function to see if a particular character is supported by the device. The client applications can use the alternative encoders using the following APIs:

Character support

The client applications can check if a character is supported by calling CSmsAlphabetConverter::IsSupportedL(TChar aChar, TBool& aIsDowngrade, TBool& aRequiresAlternativeEncoding) and CSmsUserData::IsSupportedL(TChar aChar TBool& aIsDowngrade, TBool& aRequiresAlternativeEncoding). These methods return the number of characters must be down-graded and if an alternative encoding is required to support the character.

Encoder information

The clients uses the CSmsMessage::GetEncodingInfoL() method to find the character support in the selected encoder. The function returns the following :

  • the number of PDUs required

  • the number of free characters in user data of previous PDUs

  • the number of characters that are not changed

The clients can use these parameter values to determine the encoder to be used for the given message.

Procedure

  1. Set alternative encoding

    The clients uses the CSmsMessage::SetAlternative7bitEncoding(TSmsEncoding aEncoding) method to request the SMS stack to use alternative encoding. The client uses the aEncoding parameter to specify the required encoding method. The encoding can be one of the following:

    1. single shift

    2. locking shift

    3. locking and single shift

    If more than one Alternative Encoder is selected by the client the SMS stack uses the encoder that converts most characters in the message. If the requested encoder is not available, the function returns KErrNotSupported.

  2. Get alternative encoder information

    The client uses the CSmsMessage::GetAlternative7bitEncoding() method to query the encoders supported by the SMS stack.

  3. Turkish character support

    The clients uses the CSmsMessage::SetAlternative7bitEncoding() method to specify the required encoding method.

    Most of the Turkish characters require Alternative Encoders for the SMS stack to encode the message without the loss of information from the message. There are three types of encoders available to support the Turkish characters:

    1. Single shift

    2. Locking shift

    3. Locking and Single shift

Supported encoders

The table describes the supported encoders. These encoders are optional and can be excluded at ROM build time. The CSmsMessage::IsSupported() method is used to determine if an encoder is available for the client applications.

Enumeration for encoder Description

ESmsEncodingNone

This is the default value which means Alternative Encoding is not used. The Eastern European characters being downgraded to the non-diacritic characters option is enabled automatically. The messages are encoded in 7-bit with acceptable representation to the receiving user.

ESmsEncodingTurkishSingleShift

This allows the use of the Turkish Single Shift table instead of the default GSM shift table. If this is used during encoding there is a 3-octet cost in the user data.

ESmsEncodingTurkishLockingShift

This allows the use of the Turkish Locking Shift table instead of the default GSM alphabet table. If this is used during encoding there is a 3-octet cost in the user data. This encoding is used only if the relevant national regulatory body has requested its use.

ESmsEncodingTurkishLockingAndSingleShift

This allows the use of the Turkish Locking Shift and/or the Turkish Single Single Shift tables instead of the default GSM alphabet and shift tables. If this is used during encoding there is a 3- or 6-octet cost in the user data. This encoding is used only if the relevant national regulatory body has requested its use.

ESmsEncodingSpanishSingleShift

This allows the use of the Spanish Single Shift table instead of the default GSM shift table. If this is used during encoding there is a 3-octet cost in the user data.

ESmsEncodingPortugueseSingleShift

This allows the use of the Portuguese Single Shift table instead of the default GSM shift table. If this is used during encoding there is a 3-octet cost in the user data.

ESmsEncodingPortugueseLockingShift

This allows the use of the Portuguese Locking Shift table instead of the default GSM alphabet table. If this is used during encoding there is a 3-octet cost in the user data. This encoding is used only if the relevant Portuguese regulatory body has requested its use.

ESmsEncodingPortugueseLockingAndSingleShift

This allows the use of the Portuguese Locking Shift and/or the Portuguese Single Shift tables instead of the default GSM alphabet and shift tables. If this is used during encoding there is a 3- or 6- octet cost in the user data. This encoding is used only if the relevant Portuguese regulatory body has requested its use.