Re: [Tuxpaint-devel] [Tuxmath-devel] Tuxpaint-devel Digest, Vol 22, Issue 12

[Ahmad S. <ahm...@gm...>]

> I am mobin(Tuxtype Indic team). Actually we added SDL_Pango support in
tuxtype for handling Indic language's rendering issues. So, if we > replace
it with fribidi, all Indic languages + some of the south Asian Languages
will face rendering issues ( shaping problem). So the expected output will
not be same. Now in kerala( a state in India has malayalam as local
language) schools we have been using tuxtype as the typing tutor. And also
the work to add all other 21 official language's support is already going
on. So it will make serious issues if we remove SDL_Pango.

> Since we have already fribidi support in SDL_Pango, I think it's very
efficiently solving both the RTL and shaping problems

Hi mobin, actually my native language is arabic which RTL and has a shaping
problems also, fribidi2 solve the shaping in arabic, but it is  very
important issue is fribidi handles shaping in other language, I don't think
so, as i understand fribidi do adhoc implementation for shaping arabic
character unlike Pango which  support OpenType (I least that what I expect).

But when proposing fribidi, i mean SDL_Pango is relatively heavier and make
porting harder, another issue raised by Tim and Caroline regarding BeOS
porting, fribidi may be useful in this case fribidi has no dependencies,
unlike SDL_Pango, so having partial RTL support is better than nothing,
specially for languages using RTL system and bidi system without need a
shaping like Hebrew, I did not means remove SDL_Pango but adding fribidi and
using configuration flags to choose the suitable library depending on the
depedenecies availability.

Finally, Thank you very much for you interesting point, This will force me
to do more investigation opentype