[GRASS-dev] Grass to Indian languages: Challenges

Here a FWD (with permission) to discuss the problem of Indian
fonts support in GRASS. I wonder if the new fond infrastructure
helps in this regards.

additional message from jitendra:

Please do give your critical comments on the website
www.pcmcgisda.org.in

Markus

---------- Forwarded message ----------
From: jitendra <jituviju@gmail.com>
Date: Aug 10, 2007 7:23 PM
Subject: Re: [OSGeo-Discuss] Grass to Indian languages : Challenges
To: Ravi Vundavalli <ravivundavalli@gmail.com>
Cc: neteler.osgeo@gmail.com, Swapnil Hajare <dreamil@gmail.com>

Dear Ravi,
it is true that we had started translating grass (version 5.1 onwards
) into Hindi and marathi around the time of the birth of indictrans
i.e circa 2003 as volunteers.
However we couldnot keep pace and did find major changes coming up .
In fact during 2004-2005, as a part of central govt project
janabhaaratii, we had plans to translate grass on professional payment
basis in 6 indian languages. But that too was not to be.
My technical guru Swapnil had this to say,"
"We had attempted localization of GRASS GIS earlier. The existing
translations for Hindi and Marathi are done by me only. But we stopped
doing that mainly because we thought there is no point in translating
interface in absence of support for rendering the indic text. GRASS
uses Tcl/Tk for interface which doesnt have support for rendering
Unicode Indic text. So even if we translate the po file, it won't be
displayed properly.
  More important thing which I was more attracted to was to add
support for Indic text label rendering in d.text.freetype (see
http://indictrans.in/~swapnil/grass_indix2_20051201.png ). I had done
this using Indix2 library which unfortunately is no more developed and
is not available on Xorg (it only works on XFree86 < 4.1). So I was
going to implement the same solution using widely used Indic rendering
engine such as Pango or Qt. "

My take on this is another short term solution pending a better solution .
This is assuming that tcl/tk can render multibyte ttf font. If so, we
can convert the text in unicode ( normally encoded to support opentype
fonts which have a rendering program as part of the font) into another
font (we call it setu series) , and use the same for display. There
is as of now no support for input in setu. A program is available to
convert the text from usual unicode to setu unicode. This will entail
hardcoding the font setu with grass tcl/tk script. This font has been
developed for devanagari but can be developed for all indian
languages.
The result of this approach can be seen on www.pcmcgisda.org.in where
we have mapserver map labels in devanagari .
This is a problem for all graphic programs which have been
internationalised for CJK with multibyte unicode fonts but have no
support for opentype.

If osgeo (international or india )can financially support this work,
we can put some effort to

find a short term quick fix,
get translations done systematically
work towards a long term solution by proposing a research program If
we put together a good effort and get support from grass developers,
We can even write a proposal for support from the Government of India
for research efforts for adding all indian language support . I am
confident we can get the support as egovrnance inititives require GIS
very intensely and widely.

I have seen the bright eyes of many bureacrats who have seen the
indian language on maps on the web to be so confident.
warm regards
jitendra

Markus Neteler wrote:

Here a FWD (with permission) to discuss the problem of Indian
fonts support in GRASS. I wonder if the new fond infrastructure
helps in this regards.

Not really.

So far as the GUI is concerned, wxWidgets might do a better job of it
than Tcl/Tk, or it might not. GRASS itself is stuck with whatever text
rendering the GUI toolkit provides.

As for R_text(): the FreeType renderer should handle right-to-left or
vertical fonts (whether or not R_get_text_box() handles them is a
different matter), but it won't handle complex layout rules. Each
character is drawn at the current point, and the current point is
advanced by the character's width vector.

Anything else (i.e. combining characters) will require someone to
provide the necessary code in a form suitable for integration.

--
Glynn Clements <glynn@gclements.plus.com>