Choosing the correct font for your job (in the context of Hindi)

This article is specific to the case of translating into the Hindi language.

A question that many of us face while starting a translation job is which font should be used for the translation.

Here are three hypothetical situations that are commonly encountered:

1. The client species a font in which he/she wants the translation.

2. You are familiar with only one font and use it always in your translation.

3. The client is not particular about the font and leaves the choice to you.

Situations 1 and 2

In the first two cases, we are apparently left with no choice but even then it will be judicious to make the choice of the font after careful consideration as it can save you a lot of time and also help you build a uniform glossary or TM (translation memory), as well as enable you to use advanced CAT tools which all require careful selection of fonts.

Situation 1

Let us take the first case where the client asks you to use a particular font for the translation. Should you start the translation in this font itself? That may not be advisable for various reasons.

Firstly you might not even know how to type in that particular font, for each font comes with a separate code page and keyboard arrangement and knowing to type in one font does not necessarily mean you will be able to type in another font. For example, if you know how type only in Mangal font, you won't be able to type in Shusha or KritiDev. The latter two have different keyboard layouts.

Secondly, the CAT tool you use may want you to use only Unicode fonts, or you may have a large glossary or TM in a Unicode font which you want to make use of. In this case you may do a first translation in a Unicode font using a CAT tool with which you are comfortable and using the glossaries and TMs you have, and after the translation is complete, to convert it into the required font. You can do this conversion by retyping the translation (if it is a small one of one or two pages) or using a suitable converter software. If the latter is the case you need to keep two things in mind:

1) How accurate is the conversion from one font to the other using the converter you have

In most cases some minor corrections have to be manually made in the converted file as the converter does not handle certain characters properly. This is the case with the conversion from Mangal to Shusha using the TBIL converter (see Resources below for a link from where you can download this converter for free). All the द्व are converted as > sign and the द्द is not converted at all. So, all these letters have to be manually converted in the final document. This will take time and so you must keep this in mind while quoting for the job or agreeing to a deadline.

2) Whether your converter can handle this font conversion

Most converters can handle only certain types of fonts and if your client wants the final translation in a font for which you have no converter and in which you don’t know how to type, then you should either decline the job at the outset or be prepared to do a two finger typing using the character map of the font. This can take an awfully long time and while quoting for the job and while accepting a deadline you must make allowance for this.

Situation 3

If the client leaves the choice of font to you, then here are some points that you should take into consideration while selecting the font for the translation.

Try to find out how the translated material is going to be used. Is it for a website or software, or is it for printing on paper? In the former case, always use a Unicode font as browsers and programming languages can recognize only Unicode fonts unless special measures have been taken while designing the website, such as font-embedding. To avoid these problems, always select a Unicode font like Mangal or Arial Unicode MS.

If it is for the purpose of printing on paper and the translated text is going to be formatted using DTP software like InDesign, FrameMaker, CorelDraw or PageMaker, remember that none of these software support Unicode and your translation in a Unicode font cannot be formatted on them. You will need to provide the translation in a non-Unicode font like Shusha, KritiDev, DV-TTSurekh, HindiSans, etc.

Here again, the best method would be to do the translation in Unicode using a CAT tool first, and then to convert the translated material into the required font before submitting it to the client.

Conclusion

The issue of font selection in translation is not a trivial issue and requires careful thought, especially when the target language is Hindi where different fonts with different code pages and keyboard layouts exist. Another point to be kept in mind is that no DTP software, including the popular ones such as InDesign, FrameMaker, PageMaker, CorelDraw, etc., supports Unicode, and therefore do not use Unicode font if the translated material has to be formatted on these DTP pakages. Use a non-Unicode font instead.

A final word of advice

To take the maximum advantage of CAT tools and to build up a large bank of TMs and glossaries, always use a Unicode font to do your initial translation and then convert it into the required font using a converter or retyping before submitting it.

Also, most CAT tools can handle only Unicode, and searchable glossaries and TMs can be built up only with Unicode fonts. The trend in software development is towards Unicode and eventually all software packages will be supporting Unicode. The current situation of many legacy fonts with different code pages and keyboard layouts is transient and will last only a few more years by which time acceptance to Unicode would become more widespread. But till then we have to learn to live with multiple fonts and the best strategy is to use a dual font approach - use a Unicode font to do the translation and to build up uniform glossaries and TMs, and then submit the final translation in the required font.

Resources

A good font converter which can convert from Unicode fonts to a good many legacy fonts and vice versa can be downloaded for free from here:

TBIL Font Converter

(You will need to have an MSN Passport. If you have a hotmail id, you have it. Use the hotmail id and passport to log into the site. Otherwise register yourself with MSN.

This converter can convert from legacy fonts into Unicode and supports many Indian languages, including Hindi. In the case of Hindi, it can also convert from Unicode to legacy fonts like Shusha, KritiDev, DV-TTSurekh, etc.)

-------------
Update

Since the publishing of this article there have been some new developments in DTP software that has bearings for this article.

With the launch of InDesign CS4, the font situation has become somewhat simplified for Hindi as InDesign CS4 now intrinsically supports Hindi in Unicode encoding. This means that now there is no need to use separate fonts for your print and online versions of the document.

There is however a catch. The support for Hindi in InDesign is not direct in the sense that Adobe has not formally announced it, although all the internals are in place in InDesign CS4. However, the user interfaces are not there in the official version of InDesign CS4. Therefore, even though this package fully supports Hindi unicode, there is no way a user can access these facilities.

Fortunately, some plug-ins are available which can unlock these resources:

• WorldTools for InDesign CS4 by Harbs at InTools.



• idRTL for InDesign CS4, by Steven F. Bryant.



• IndicPlus, by MetaDesign, for InDesign CS2 and CS3.


There are a number of links that discuss these plug-ins in detail. Please refer to them for more information:


• Word-Ready Composer



• Phiny On Fonts



• InDesign CS4's Hidden Word Ready Composer



It is hoped that InDesign CS5 will come complete with the user interfaces for Hindi and that will make this article really irrelevant, for then it will be possible to use the same unicode Hindi font for both print and online edition of documents.