New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Indic OpenType Font rendering with ICU 'Shaping' #112

Closed
artemp opened this Issue Oct 11, 2011 · 15 comments

Comments

Projects
None yet
4 participants
@artemp
Member

artemp commented Oct 11, 2011

Arabic font rendering with ICU is clearly supported, as I can see the routines here:

http://trac.mapnik.org/browser/trunk/include/mapnik/font_engine_freetype.hpp#L257
and the news here:
http://mapnik.org/news/2008/feb/20/mapnik_unicode/

Indic font rendering apparently needs its own special routines which are discussed in the context of OpenType fonts here:

http://trac.osgeo.org/mapserver/ticket/2591

Context: when gargi.ttf is configured based on this readme:
http://mapnik-utils.googlecode.com/svn/example_code/fonts/README.txt
the result is the same as the graphics attached to the mapserver ticket.

Thus, enhanced support for OpenType Indic fonts is highly desirable within Mapnik.

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] See Ticket #19 for context on why ICU can solve this problem.

Member

artemp commented Oct 11, 2011

[springmeyer] See Ticket #19 for context on why ICU can solve this problem.

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] I tried applying the patch from http://lists.openstreetmap.org/pipermail/dev/2008-October/012005.html

and I've attached a graphic comparing the raw text in the postgres insert of sample indic data (from the linked mapserver ticket) to the rendered text. I'm not sure which is right and which is wrong, so feedback is welcome.

Member

artemp commented Oct 11, 2011

[springmeyer] I tried applying the patch from http://lists.openstreetmap.org/pipermail/dev/2008-October/012005.html

and I've attached a graphic comparing the raw text in the postgres insert of sample indic data (from the linked mapserver ticket) to the rendered text. I'm not sure which is right and which is wrong, so feedback is welcome.

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] data and test case script's to produce the previously attached image are here: http://mapnik-utils.googlecode.com/svn/trunk/tutorials/fonts/

Member

artemp commented Oct 11, 2011

[springmeyer] data and test case script's to produce the previously attached image are here: http://mapnik-utils.googlecode.com/svn/trunk/tutorials/fonts/

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] The link has now moved for the testcase to:

http://mapnik-utils.googlecode.com/svn/sandbox/indic_fonts/

Member

artemp commented Oct 11, 2011

[springmeyer] The link has now moved for the testcase to:

http://mapnik-utils.googlecode.com/svn/sandbox/indic_fonts/

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[pavithran] [[Image(telugu-example.png)]]

Town/city names in India can't be localised because of this bug . This bug affects almost every town/city in northern india where hindi language is predominantly used .

I have attached an example showing proper rendering of telugu . We used to have these issues with pango long back . They were solved by installing ttf-indic-fonts . Pango rendering issues are long gone and almost all major rendering engines render indic fonts .

Member

artemp commented Oct 11, 2011

[pavithran] [[Image(telugu-example.png)]]

Town/city names in India can't be localised because of this bug . This bug affects almost every town/city in northern india where hindi language is predominantly used .

I have attached an example showing proper rendering of telugu . We used to have these issues with pango long back . They were solved by installing ttf-indic-fonts . Pango rendering issues are long gone and almost all major rendering engines render indic fonts .

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[pavithran] ICU was rendering telugu fonts ( atleast to some extent) as per http://bugs.icu-project.org/trac/attachment/ticket/6113/gautami.pdf for the version 3.6 though there is a slight positioning bug http://bugs.icu-project.org/trac/ticket/6113

Member

artemp commented Oct 11, 2011

[pavithran] ICU was rendering telugu fonts ( atleast to some extent) as per http://bugs.icu-project.org/trac/attachment/ticket/6113/gautami.pdf for the version 3.6 though there is a slight positioning bug http://bugs.icu-project.org/trac/ticket/6113

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[jburgess777] I'm adding a comment at the request of pvai on IRC (pavithran), I think this information is known already but is not mentioned in this bug. I believe the underlying issue here is that Mapnik is rendering the string one character at a time in order to make the characters follow along the path. These Indic languages use ligatures where the rendering depends on multi-character sequences and can not be correctly rendered one character at a time, http://en.wikipedia.org/wiki/Typographic_ligature

For reference, the location which pavithran supplied can be seen at: http://www.openstreetmap.org/?mlat=17.25&mlon=80.15&zoom=12

Member

artemp commented Oct 11, 2011

[jburgess777] I'm adding a comment at the request of pvai on IRC (pavithran), I think this information is known already but is not mentioned in this bug. I believe the underlying issue here is that Mapnik is rendering the string one character at a time in order to make the characters follow along the path. These Indic languages use ligatures where the rendering depends on multi-character sequences and can not be correctly rendered one character at a time, http://en.wikipedia.org/wiki/Typographic_ligature

For reference, the location which pavithran supplied can be seen at: http://www.openstreetmap.org/?mlat=17.25&mlon=80.15&zoom=12

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] fyi, new shaping library: http://cgit.freedesktop.org/harfbuzz/

Member

artemp commented Oct 11, 2011

[springmeyer] fyi, new shaping library: http://cgit.freedesktop.org/harfbuzz/

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Oct 11, 2011

Member

[springmeyer] fyi, make sure to see Tom's comment on ICU and Shaping: https://lists.berlios.de/pipermail/mapnik-devel/2010-September/001245.html

Member

artemp commented Oct 11, 2011

[springmeyer] fyi, make sure to see Tom's comment on ICU and Shaping: https://lists.berlios.de/pipermail/mapnik-devel/2010-September/001245.html

@mikelmaron

This comment has been minimized.

Show comment
Hide comment
@mikelmaron

mikelmaron Mar 15, 2012

This issue came up in the Cartonama workshop a couple weeks ago. Added Kannada names to the map, and they didn't render properly. Working properly, this is a huge bonus for the open toolset in India.

I don't have the expertise to get involved, but could ask some folks in India if they might be able to contribute. Is the problem defined enough for that kind of help?

mikelmaron commented Mar 15, 2012

This issue came up in the Cartonama workshop a couple weeks ago. Added Kannada names to the map, and they didn't render properly. Working properly, this is a huge bonus for the open toolset in India.

I don't have the expertise to get involved, but could ask some folks in India if they might be able to contribute. Is the problem defined enough for that kind of help?

@herm

This comment has been minimized.

Show comment
Hide comment
@herm

herm Jun 25, 2012

Member

This bug should be fixed when we switch to HarfBuzz as our shaping engine. It shouldn't need any special handling.

Member

herm commented Jun 25, 2012

This bug should be fixed when we switch to HarfBuzz as our shaping engine. It shouldn't need any special handling.

@mikelmaron

This comment has been minimized.

Show comment
Hide comment
@mikelmaron

mikelmaron Jun 27, 2012

good to here ... when will this take place approximately?

mikelmaron commented Jun 27, 2012

good to here ... when will this take place approximately?

@herm

This comment has been minimized.

Show comment
Hide comment
@herm

herm Jun 28, 2012

Member

Except first results in a few weeks and final code in about 2 months (in git). I'm not sure when a version containing the new code will be released.

Member

herm commented Jun 28, 2012

Except first results in a few weeks and final code in about 2 months (in git). I'm not sure when a version containing the new code will be released.

@ghost ghost assigned herm Jun 28, 2012

@gisupc

This comment has been minimized.

Show comment
Hide comment
@gisupc

gisupc Jul 3, 2012

work with CJK support ?

gisupc commented Jul 3, 2012

work with CJK support ?

@herm

This comment has been minimized.

Show comment
Hide comment
@herm

herm Aug 21, 2012

Member

Closing this ticket as the issue is solved in the harfbuzz branch. Refs #1428.

Member

herm commented Aug 21, 2012

Closing this ticket as the issue is solved in the harfbuzz branch. Refs #1428.

@herm herm closed this Aug 21, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment