Today I would like to offer a guide to change the font to your Symbian S60v3.
First council to have already installed on your mobile phone file manager like X-plore.
As a first step download and install the program to fund post FontRouter LT (usigned, and by sign) on the memory card in your phone.
Once installed in E: \ (or E: \ data \ Fonts) you will find a file called FontRouter.ini.
From here, or with X-plore or via PC with Notepad, open the file and tweak the following parameters:
Force to enable anti-aliased bitmap type for True Type fonts.
ForceAntiAliased = 4
Fix Font Metrics (expecially necessary for East-Asian language fonts)
FixFontMetrics = 1
Fix character metrics automatically (for characters not fit the font metrics)
FixCharMetrics = 1
I inserted a copy already changed at the end of post, so if you do not want to change themselves, change with that found in E: \.
Save and reboot the phone.
You'll notice that the font is a little 'smaller and more sharp.
Now switch to X-plore.
Create a new folder named "Fonts" (without quotation marks), if not already has been created in E: \ data, and creating the path E: \ data \ Fonts, where you have to copy the file inside FontRouter.ini changed.
Create a new folder named "Fonts" (without quotes) in C: \ data, so that the path C: \ data \ Fonts, where you must enter the desired font.
Restart to make sure that your font is loaded.
Again to change fonts, add another in the same folder C: \ data \ Fonts with a name that, in the alphabetical order of the letters come before the one already inserted, for example between fonts and Comics Sans MS Times New Roman is loaded the Comics Sans.
WARNING: It is possible that the procedure does not lead to a successful conclusion.
The procedure is tested working on N73 and N95.
Never restarts the phone if you have the folder C: \ data \ Fonts, there is no font added, deleted the folder instead.
This is because otherwise the phone will crash and restart with a Hard Reset.
Style Blog Tech does not assume responsibility if the procedure will cause damage to your phone.
* Download FontRouter LT (35 KB)- MediaFire
* Download FontRouter.ini (2 KB) - MediaFire
Amoebax is a puzzle game like Puyo Puyo, available for all mobile phones with Symbian OS Series 60 third edition.
The goal of the game is very simple, it must match the blob of the same color to create huge chains and make them disappear from the screen. The blob fall into groups of two or more elements, and can be rotated and moved in position to facilitate the mission.
Amoebax is not a champion of originality and the similarity with Puyo Puyo is obvious. The game has a graphics very colorful and cheerful.
Download Amoebax Puzzle Games Symbian here
Developers can localise a C++ application by simply changing the resource file text associated with each menu item, task bar or other control. Since changes to the text do not change the symbol information in the generated header file, it is not necessary to recompile the application to use the new file. Consequently, a resource file may be generated for each language supported, and the actual resource used is determined by the end-user at installation time.
The examples quoted in this page are taken from the code example Examples\ToolsAndUtilities\Localise, which provides the Hello World application, localised for English and German.
Localisable strings
Localisable strings should not be defined within a resource file, but in separate files with the extension .rls. An .rls file defines symbolic identifiers for strings, to which the resource file refers when it needs the associated string.
An example from an .rls file is shown below:
// Strings localised for UK
rls_string STRING_r_example_first_menu_name "Hello"
rls_string STRING_r_example_item0 "Item 0"
The keyword rls_string appears before each string definition, followed by a symbolic identifier, and then the string itself in quotes. To localise the file for German, the same identifiers would be used, but the strings would be translated, i.e.
// Strings localised for German
rls_string STRING_r_example_first_menu_name "Hallo"
rls_string STRING_r_example_item0 "Eintrag 0"
The resource file itself would be the same, whatever the locale, as it would only refer to strings through their symbolic names, e.g.
MENU_TITLE
{
menu_pane=r_example_first_menu;
txt=STRING_r_example_first_menu_name;
}
defines a menu title resource, with a title string defined by STRING_r_example_first_menu_name (i.e. "Hello" in UK, "Hallo" in German).
Building localised resource files
You can define in a project definition (.mmp) file the locales that the project supports. Given appropriate resource source and .rls files, the build process then builds a separate compiled resource file for each supported locale.
The process in detail can be broken into three steps:
determine on a symbolic identifier for every supported locale
specify in the project definition file the supported locales
#include the .rls files for the supported locales in the resource source file
These are discussed further below.
Locale identifiers
You should decide on a symbolic identifier for every supported language. The symbol should be of the form:LANGUAGE_language-code
where language-code should be two characters long, but otherwise can be anything you like, as long as each language in the resource file has a unique symbol.
You are recommended to use a standard two-digit number as defined by Symbian in an enumeration TLanguage in e32std.h, which gives numeric values to the languages. For example, the value ELangGerman (German) in TLanguage has the value 3, so you could use LANGUAGE_03 as the symbol for German.
Alternatively, you can use logical letters for each language: e.g. US English might have the symbol LANGUAGE_US, while French might have the symbol LANGUAGE_FR.
Project definition files
For projects with localised resources, you must use the lang statement in the .mmp file to set the languages codes used. So, for the above example, in which the language codes used are for German (03) and UK English (01), the lang statement should read:
lang 01 03
When the project is built, each resource file specified in the project file will be compiled multiple times, once for each language-code specified. The language codes are used to complete the extension of the built resource files: for our example, two files would be built: project-name.r01 and project-name.r03.
Resource source files
The symbols can then used, with conditional compilation statements, to specify which string definitions should be compiled for each language. In the example code fragment below, the file 01-strings.rls is assumed to have the strings localised for UK English, and the file 03-strings.rls the strings localised for German.// Conditional compile, depending on locale
#ifdef LANGUAGE_01 // if language code is for UK
#include "01-strings.rls"
#elif defined LANGUAGE_03 // if language code is for German
#include "03-strings.rls"
#endif
// end conditional compile
when built with the code 01, the UK English strings in 01-strings.rls are compiled into the resource file
when built with the code 03, the German strings in 03-strings.rls are compiled into the resource file
How programs load resource files
The Uikon application framework attempts to load the project's resource file when the application starts up. If the resource file has the extension .rsc, then this is loaded. Alternatively, the framework attempts to load the correct resource file by comparing the system locale setting with the available resource files: for example, in a German locale, the resource file with extension .r03 would be loaded. Resource files that are explicitly loaded by programs, rather than by the framework, can use the same stategy, by calling BalfUtils::NearestLanguageFile() to find a resource file with the correct language extension.
More typically than installing all the resource files for all the available locales, you would only want to select a single resource file for installation, based on the system locale or user preference. The Symbian OS Installation System enables this, as described in How to create an installation file for a multilingual application.
Introduction
In S60 3rd Edition application development all .sis files must be signed before installing them to a device. When an application requires no capabilities or utilizes APIs which are open to all, you can use the Self Signed certificate. This can be used when testing an application inone’s own device or when shipping the application. Using the Self Signed certificate is recommended for freeware applications using unrestricted capabilities.
Self Signed Certificate
When an application requires no capabilities or utilizes APIs, which are open to all. This can be used when testing an application in one’s own device or when shipping the application.
Note: The application is regarded as Untrusted if signed with the Self Signed Certificate.
This process is recommended for freeware applications using unrestricted capabilities(User grantable capabilities)
Developer Certificate
When testing the application in developer’s own device(s). This certificate is received from Symbian.
The Symbian Developer Certificate can be used by developers to sign their applications in order to obtain the restricted capabilities for device testing. The certificate is restricted to a certain set of IMEIs and the set cannot be changed. There are a few requirements to get a Symbian Developer Certificate.
Symbian Signed
Mandatory if the application is using capabilities beyond the scope of APIs open to all and the application is shipped.
This is the sets of certificates respeected to APIs utilized.
60% of APIs (no restricted certificate)
User-Grantable Capabilities (need atleast self signed certificate)
ReadUserData
WriteUserData
NetworkServices
LocalServices
UserEnvironment
Symbian Signed Capabilities (need Symbian signed certificate)
User-Grantable Capabilities + sets of following
Location
ReadDeviceData
WriteDeviceData
PowerMgmt
SurroundingsDD
ProtServ
TrustedUI
SwEvent
Licensee/Platform Approval Capabilities (need Symbian signed certificate)
Symbian Signed capabilities + sets of following
Manufacturer
DRM
TCB
S60
DiskAdmin
AllFiles
CommDD
MultiMediaDD
NetworkControl
For more access capabilities details see also Enum TCapability
Sign SIS file
To self-sign the sis file with SISWare you must have the key file(.key) and certificate file(.cer).
The key file and certificate file may be given Symbian Signed Certificate from trusted Certificate Authority such as Verisign
and Symbian Signed or create your own self-sign certificate
To use the SISWare's sign tool, go to menu Tools ---> Digitally Sign Tools.
At Sign SIS File tab, follow these steps.
1. Specifile original SIS to be signed, this file will not effacted by signing process. The result of signing process is the target signed sis file.
2. Specify the target sis file which will create.
3. Specify key file
4. specify certificate file
5. Specify password(if that certificate file encrypted with password)
6. Specify algorithm. If you use symbian tool named makekeys.exe (even use in SISware) to produce key and certificate file, please choose DSA algorithm because that file created with that algorithm.
7. Click Sign button.
If no error occurs the signing will complete with some signature information that given by certificate file that seen from Signing Info box. Then this signed sis file will be able to install to Symbian9.x OS devices.
Create self-sign certificate file
You can create your own key and certificate file to use in signing process and your sis file will be regarded as Untrusted. To create key and certifiate file, go to Create Self-Signed Certificate tab in Digitally Sign Tools window
