Thread: Firefox, OpenOffice and Linux distributions

The premise behind Open Source development is giving, sharing and collaborating willfully. Individuals and organizations in India and around the world, work in teams to jointly develop or maintain an application or operating system. It is not uncommon to see many in this community rendering their services and time free-of-cost.

To an "outsider" this may sound like a strange way of working. Why would a full-time employee of Red Hat contribute to another Open Source initiative? And why would a student distribute copies of Fedora at his expense? Why is it so important to work in an upstream manner? To find out, CHIP visited the Red Hat Engineering Center in Pune. Sankarshan Mukhopadhyay, Manager Software Engineering at Red Hat Software Services (India) told us how it all works in the Open Source world. Sankarshan briefed us about various projects and initiatives at Red Hat.

The Red Hat Engineering Center (RHEC) is primarily an engineering and support center. It undertakes back-end application development (aimed at meeting the requirements for internal infrastructure). It provides support for Red Hat Enterprise Linux (RHEU and other products from the Red Hat family, such as Mobicents and JBoss. Red Hat also contributes to the Open Source community. It mentors students and developers, supports community development, and participates in the Fedora project. It creates awareness about the Open Source community and its projects in academic institutions.


Localization

A main focus area for the engineering team is localization. The team works on the development of fonts and user interfaces that are used in Open Source applications such as those from the Mozilla Foundation, upstream projects (Gnome, KDEl, or in Linux distributions (Red Hat, Fedora, Ubuntu, Debian etc).

There are many challenges when it comes to developing local language fonts, or 'Indics' as these are commonly called. For one, there's an absence of standards for sorting characters in a language. To overcome all these challenges Red Hat engineers collaborate with many government institutions to set non¬conflicting standards, before working on the code.

Localization efforts are directed towards making the user interface available in local languages and making local language fonts available. There are three aspects to localizing an operating system: display, printing and input. Traditionally, every language has various types of keyboard layouts, and various governments have their own keyboard layouts. So it's about making those available in Linux using the input method framework that is already in place. And this is what the RHEC was doing at the initial stage.

Localization efforts at the RHEC began just before the launch of RHEL 4. The objective then was to provide support for five Indic languages (Indian native language support or Indian language localization). The work of localization happens simultaneously for the Fedora Project as well as Red Hat Enterprise Linux. This covers areas of user-interface localization and documentation among other important things.

Native Language Support for an Operating System or a project goes beyond localizing the user interface or preparing the documentation. It involves putting in a framework that provides paths to solutions for the three aspects of display/rendering, printing and input. This means development teams need to work on keyboard layouts, input methods, OpenType fonts etc. Red Hat's engineering team works on SCIM (Smart Common Input Method) and the associated backend m17n libraries, the Lohit series of OpenType fonts, as well as developing and enhancing rendering engines like Pango and Cairo that are consumed by the various applications on the system to handle local language content.



Challenges

Once work on localization began, the RHEC turned its attention to getting various building blocks in place. When it came to addressing the sorting order of characters, they faced some big challenges. While character sorting is straightforward for the English alphabet, it's more complex for Indian languages which have conjuncts (two characters combine to form a third character). and accents like hal/ant. Now this can either result in a separate character or a separate character shape, which is called a 'glyph'. Ironically, no Indian language has the sort order completely specified. For example, two kinds of sorting orders exist for three particular sets of characters.

Fixing the sorting order and collation sequence needed work on glibc-the library that is consumed by any application that desires to incorporate native language support. The work on glibc from the perspective of collation sequence is another building block towards providing an improved end-user experience of the native language enhancements. Glibc is considered to be Linux plumbing and it is an example of working higher up in the development chain at an upstream level, rather than specifically to the implementation in the distribution layer.

Right now RHEC is working on 11 Indic locals with the aim to cover more, and on improving availability. This work would involve working with the Unicode Consortium towards fixing issues in Unicode encoding along with ensuring that the components of the language support are in place.

So how did RHEC tackle the issue of standards? The trick was to work in an upstream manner and collaborate with the Open Source development community, government institutions, and language communities.

Working Upstream

Red Hat collaborates with research bodies and the open source community on various projects in an upstream manner. It claims that its engineering efforts are not only for commercial gain, but are also a contribution to the Open Source community.

During the RHEL 4 phase, Indic for Linux was very nascent. So the primary activity at that time was building ties with various bodies. Red Hat also directed its efforts to building communities around its engineering efforts.

Being an "upstream contributor", Red Hat followed the Open Source model while working on Indic issues. The reason for this seems obvious. Limiting evolutionary enhancements and fixes to only Red Hat Enterprise Linux or Fedora would have led to the consumption and feedback loop from a limited section of the user base. Working upstream ensures that all distributions can benefit, and the project achieves the objective of becoming a framework.

For example, aspects like SCIM and fonts are best handled upstream, so that other distributions like OpenSuSE, Debianl Ubuntu can package them accordingly and ship them as part of their releases. The other driver for working upstream and creating a framework is that it allows a larger number of organizations and standards bodies to contribute and participate in fixing issues. They can collaborate and produce incremental iterations and improvements. A benefit of such a workflow is that standards can be implemented across all Operating Systems and applications. The Red Hat team continues to work in an upstream manner to constantly evolve, modify and advocate Open Standards .