Opened 16 years ago

Last modified 15 years ago

#2591 new defect

Indic Rendering Support Lacking

Reported by: dreamil Owned by: sdlime
Priority: normal Milestone: FUTURE
Component: MapServer C Library Version: unspecified
Severity: normal Keywords: indic rendering
Cc: dmorissette, springmeyer, tbonfort

Description

The current version of Mapserver can render labels on map using LABEL directive in a map file.For labels, you can use truetype fonts which is achieved using freetype.Due to this map labels can be displayed in various non-English languages such as europian and some Asian scripts.

However, for rendering some CTL (Complex Text Layout) scripts, truetype fonts are not sufficient.Indic Scripts, for example, require much more than mere juxtaposition of glyphs from a font.Rendering Indic scripts such as Devanagari, Gujarati, Tamil, Telugu, Bengali etc. is much more complex than others.To handle this, "intelligent" fonts were designed which contain embedded rules to help rendering.These were called OpenType fonts (see http://www.microsoft.com/typography/otfntdev/indicot/default.htm). Though initiated by M$, OpenType fonts are are now Industry standard for rendering these complex scripts on Computer using script and language rules. All major Linux desktops such as GNOME and KDE support OpenType font rendering.To handle OpenType fonts, various rendering engines have been developed and have become part of rendering libraries such as Pango(http://www.pango.org/)/ICU(http://www.icu-project.org/), Qt etc.It should be noted that, in absence of such a rendering engine, OpenType fonts act as Truetype fonts i.e. the embedded rendering rules are not used while doing the glyph formation.

There are numerous OpenType fonts available free/proprietory for Indic scripts. We have ourselves developed gargi, the first GPLed OpenType font for Devanagari(http://savannah.nongnu.org/projects/gargi).

Current Mapserver supports truetype fonts using freetype routines, but there is no support for OpenType fonts. As a result, a text label in any of the indic scripts is rendered using justaposition of glyphs from the font provided, without using rendering rules.The result is incorrect rendering. To show you the difference, here is the snapshot of a map with labels in Devanagari script (which is a indic script), rendered in correct fashion(http://indictrans.in/~swapnil/mapserver/required_result.png) and here is the snapshot as rendered by Mapserver(http://indictrans.in/~swapnil/mapserver/mapserv_no_render_support_for_ttf.png) You may not be able to make out much if you are not familiar with the script, but for someone who knows the script, its an incorrect or broken representation of the text.

To solve this, we should add support for OpenType font rendering in Mapserver.This can be done by embedding some indic rendering routines from Pango or ICU into the label rendering engine of mapserver. I don't know the details of how labels are rendered in Mapserver, so somebody knowledgable should guide. I am prepared to take up the task on behalf of my team (www.indictrans.in) if I get some guidance about internal working of Mapserver.As far as performance is concerned, this will hit the speed badly, but then this can be encoded as a configure options (--with-pango similar to Firefox implementation http://developer.spikesource.com/wiki/index.php/Firefox_Indic_Build) so that it becomes optional.

You may have look at the temporary solution which we are using for the time being to show indic text on maps using Mapserver here: http://www.indictrans.in/old/doublebyte/English/doublebyte_l10n_25march_4PM.html We have numerous localized GIS demo on our website using this approach.

Attachments (1)

problem_example.png (47.7 KB ) - added by springmeyer 15 years ago.
Example of rendered indic font and original font

Download all attachments as: .zip

Change History (10)

comment:1 by sdlime, 16 years ago

MapServer itself doesn't render fonts. We ensure that strings are encoded properly and then hand them off to either GD or AGG (which subsequently call freetype) for rendering. I know GD does or is planning to support Pango, I'm not sure about AGG.

I'll be happy to help you wade through the MapServer internals. This would be a nice addition.

Steve

comment:2 by dmorissette, 16 years ago

Cc: dmorissette added

comment:3 by sdlime, 16 years ago

Milestone: FUTURE

dreamil, any movement?

Steve

comment:4 by springmeyer, 16 years ago

Cc: springmeyer added

dreamil, a small sample dataset posted here would be useful for testing.

comment:5 by dreamil, 16 years ago

You can download a postGIS table dump from http://indictrans.in/~swapnil/mrdata.sql.zip This is dump of postgresql table mrdata which has a column named "mr" containing some data in Devanagari script. You can use this column as label and use gargi font (http://download.savannah.gnu.org/releases/gargi/gargi.ttf) for rendering the label. If you are on Ubuntu, you can simply apt-get install ttf-indic-fonts to get the indic fonts installed.

I will shortly post the existing rendering of the data using mapserver and expected correct rendering for verification.

comment:6 by tbonfort, 16 years ago

Cc: tbonfort added

comment:7 by springmeyer, 16 years ago

For reference, the parallel discussion in the mapnik community: http://trac.mapnik.org/ticket/112

comment:8 by springmeyer, 15 years ago

dreamil,

Have you had a chance yet to produce graphics from that sample data showing exactly what is wrong?

I took a crack at doing so and am attaching a screenshot of rendered text that is not correct and a bit of original text copied out into an editor window from the sql dump (which I think is correct).

Can you help confirm?

by springmeyer, 15 years ago

Attachment: problem_example.png added

Example of rendered indic font and original font

in reply to:  8 comment:9 by dreamil, 15 years ago

Replying to springmeyer: yes, from the snapshot you have attached, the text displayed in editor is the way the text should be rendered using a OpenType rendering engine. The text displayed on map is incorrect and as a result of lack of opentype rendering support.

Note: See TracTickets for help on using tickets.