Re: Re: issue with Devanagari rendering

2014-01-08 Thread Parth Kanungo
Title: Samsung Enterprise Portal mySingle


Hi Steve, 

Thanks for the reply.
By "rendering", I meant the FT_Bitmap that is created after using pango_ft2_render_layout() API. 
I had flushed the bitmap into an image file for viewing the output.

Yes, I am using Unicode character encoding to render the text. And, you are again correct that this is related to the "input method".
So, a user can type halant, 0x094D, which is invalid without a preceding consonant, but shall nevertheless be rendered.

The output I expect with the string 
{0x094D, 0x0930} 
is a halantbelow adotted circleand a ra, र

On further investigation, I found that eventhis string 
{0x094D, 0x0930,0x094D, 0x0930,0x094D, 0x0930}
shows wrong output.

Can you suggest what could possibly be wrong here?
I feel that some change is required in hb-ot-shape-complex-indic.cc.

Thanks and regards,
Parth Kanungo





--- Original Message ---
Sender : Steve Whitestevan.wh...@gmail.com
Date : Jan 08, 2014 20:14 (GMT+05:30)
Title : Re: issue with Devanagari rendering


Hi, Parth,
There is some confusion here, so that it isn't clear even what you're asking.Usually in these contexts, the term "rendering" refers to the graphical output of a complex process.
You have provided a list of numbers ending in a null character. This could be interpreted many ways.
The order in which characters from a given character encoding are arranged, is again called the "encoding".
It appears that you are using the Unicode character encoding. The null has nothing to do with the encoding--it's not a valid character in Unicode.
In the Unicode standard, valid orders for Devanagari characters are specified.
You may want to look at The Unicode Book, Chapter 9.
All modern systems use this encoding to interpret Devanagari text.

Furthermore, a separate issue is the "input method", which is the way in which a user types or inputs the text.
So... it isn't clear what you intend to happen with this string.
As you see, the halant u+094D has very special behavior in the Unicode encoding.

Just what did you expect to see? How were you viewing this string?
Cheers!

On Wed, Jan 8, 2014 at 2:24 PM, Parth Kanungo part...@samsung.com wrote:


Hello,

I was trying to render the string 
{0x094D, 0x0930, 0x}
The rendered output is incorrect.

It might be grammatically inaccurate to place 0x094D (halant)as the first character.
However, my application requires such an independent rendering.

Can you tell me how I can go about rendering the given Unicode?

Thanks and regards,
Parth Kanungo


___gtk-i18n-list mailing listgtk-i18n-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtk-i18n-list





___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list


Re: issue with Devanagari rendering

2014-01-08 Thread Behdad Esfahbod
On 14-01-08 11:21 PM, Parth Kanungo wrote:
 On further investigation, I found that even this string
 
 {0x094D, 0x0930,0x094D, 0x0930,0x094D, 0x0930}
 
 shows wrong output.

Get a non-broken-beyond-repair font.  Ie. remove freesans from your system.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list


Re: issue with Devanagari rendering

2014-01-08 Thread Werner LEMBERG

 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.

Hmm.  FreeSans is actively developed, as far as I know.  So why not
contact the author so that he fixes such issues?


Werner
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list


Re: issue with Devanagari rendering

2014-01-08 Thread Behdad Esfahbod
On 14-01-09 02:19 PM, Werner LEMBERG wrote:
 
 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.
 
 Hmm.  FreeSans is actively developed, as far as I know.  So why not
 contact the author so that he fixes such issues?

The maintainer is in fact CC'ed on this message already.  Recent versions have
fixed a lot, but the version stuck on most Linux distros is beyond repair in
the shaper.

In general, I've found that both GNU freefonts and GNU unifont have a
quantity-over-quality mindset that is quite hurtful IMO.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list