weBLOGic

Official binary releases from the Mozilla Corporation by default do not render Indic fonts correctly. The reason is official binary release is not compiled with pango support. Pango is a font rendering engine with focus on l18n. The pango layout engine is basically designed in context with gtk+ widget toolkit. Pango works on multitude of platforms like Linux, MacOSX and M$.

Most of the Indic scripts fall under Complex Languages which require special rendering. To enable this under Firefox we need to recompile the source with just one extra option i.e. –enable-pango.

Marathi (Devnagari) fonts rendered by official binary release is shown in image below.

Marathi fonts rendered by custom built Firefox is shown in image below.

You can clearly see the difference in font rendering.

Download and build Firefox

To compile Firefox, download firefox source from mozilla.org after selecting source directory under appropriate version (2.0.0.5 in this case). The source itself is 35 MB, after bunzipping it expands to whopping 345 MB.

tar xjf firefox-2.0.0.5-source.tar.bz2
cd mozilla

Next step is to create a configuration file. There is a utility for building configuration file (called mozconfig) from Mozilla located here, which makes life a little easy.

It is better to create mozconfig file which include existing build options. You can view the official binary release build option by typing about:buildconfig in address bar of official release Firefox. Below are build options used for binary release:

–enable-application=browser –enable-update-channel=release –enable-update-packaging –enable-official-branding –disable-debug ‘–enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+’ –disable-tests –enable-default-toolkit=gtk2 –enable-xft –disable-freetype2 –enable-svg –enable-canvas –enable-static –disable-shared

As can be seen here official release Firefox is not compiled with pango support. As you can see, this build is going be static with just one extra option i.e. –enable-pango. The mozconfig file created for custom compilation looks like the one shown below:

# Options for client.mk.
mk_add_options MOZ_CO_PROJECT=browser
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-static

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-application=browser
ac_add_options –enable-update-channel=release
ac_add_options –enable-update-packaging
ac_add_options –enable-official-branding
ac_add_options –enable-pango
ac_add_options –disable-debug
ac_add_options ‘–enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+’
ac_add_options –disable-tests
ac_add_options –enable-default-toolkit=gtk2
ac_add_options –enable-xft
ac_add_options –disable-freetype2
ac_add_options –enable-svg
ac_add_options –enable-canvas
ac_add_options –enable-static
ac_add_options –disable-shared

Please note that in above file I have used –enable-official-branding which makes use of all the trademarked logos while building. However, you should not use this if you are planning to distribute binary, unless you have obtained express permission from Mozilla. Read Mozilla Licensing Policies. As long as you are building it for yourself, you can use anything you want.

Assuming your Mozilla source is in mozilla directory, you can keep this file in this top level source directory with name .mozconfig as a convension. Actually you can keep this file anywhere and export a shell environment variable MOZCONFIG pointing to an absolute path to this file. But this is volatile.

I personally prefer to keep it in top level source directory and export path as a precautionary measure. Next is to issue make command.

export MOZCONFIG=/absolute/path/to/mozilla/.mozconfig
make -f client.mk build

While compilation process is on, you can get caffeinated enough so you can stay up for further tests. On my Celeron 1.7 GZ laptop with 768 MB memory it took freakin 2.5 hours to finish compilation. Most of the compilation is CPU hogging, with constant average CPU usage nearing 95%. This sent load average on my machine to a soaring 4 to 7. Most of the compilation time I had a table fan spinning in full swing facing my lappy as it started heating up like anything in first few minutes itself.

Only last step where it binds some big object files together and finally the firefox-bin binary is memory intensive. It took most of my available memory and all of the CPU bringing other tasks on lappy to a screeching halt.

Big Phat Warning: The official document states that it requires 1.5 GB disks pace for static and XULRunner builds, mine took 2.7 GB. So keep at least 3 GB of disks pace free on the partition where you are compiling Firefox. You WILL run into troubles if its your root partition with /tmp on it and is filled to the brim.
Initially I had just 2 GBs of disk space free on root partition. I thought it would work but did not consider the disk space used by /tmp and space used by sources. Obviously in first try it failed due to lack of disk space. Next I freed up some more space. After everything was compiled properly it took around 2.7 GB of disk space.

After the compilation is complete you can test the new build by running file /absolute/path/to/mozilla/ff-opt-static/dist/bin/firefox. Once you are satisfied with the new build, you can create a tar file which then you can copy on any location you want and run from there. This can be created by running command

make -C ff-opt-static/browser/installer

This would create file firefox-2.0.0.5.en-US.linux-i686.tar.gz in mozilla/ff-opt-static/dist/ directory. That completes building Firefox from source.

The memory footprint did not change for custom built Firefox compared to that of official release. Being static build, memory footprint is rather large (34MB resident and around 14 MB shared) compared to other applications. Its same for official release as well as custom build. I am yet to detect any memory leaks in my build.

Most of the documentation you can find on developer.mozilla.org.