On Sun, 8 Oct 2006 09:01:59 +0200 wagner frederic <[EMAIL PROTECTED]>
babbled:
> hi everyone,
>
> i recently started a small app to help me learn arabic with etk and evas.
hey cool - salam effendi! :) (there goes my entire arabic knowledge!) :)
> after finishing the gui i realized evas text handling doesn't support arabic.
yup! :) correct. i'd love to support arabic, hebrew etc. (also know as RTL
languages (right to left)), BUT 1. i know none of them, 2. there has never been
any heavy push by users for such support. so it's basically been ignored.
from my understanding we have a few things to solve.
1. combined glyphs. this is where in arabic you encode several characters one
after the other but they get drawn on top of eachother to compose a new
character - beats me exactly what the details are beyond that - thus i haven't
touched it.
2. right to left - not too hard, but we just need to walk to the left, not the
right when drawing.
3. combined strings. when a string has both left-to-right and right-to-left
text in it life gets tough as you swap drawing direction half-way-through
(compared to encoding direction). eg - an arabic string with english in the
middle or the other way around.
after basic string drawing handles this you then have the added work of
textblock needing to deal with this too (now).
so there is what i know about the problem - and that's about where my knowledge
ends :)
> after a bit work i've managed to get it working.
>
> basically there are three problems to manage :
>
> 1) write from right to left (not just reverse the string as inside one string
> unmbers and foreign words need to be written in left to right)
yup. not too trivial - but not too hard either.
> 2) to some glyph shaping : in arabic, the shape of the letter depends of its
> position in the word so each char needs to be replaced by the corresponding
> one
also glyph combining too. :)
> to handle these two steps I used the code from the minibidi project from
> arabeyes.org
>
> at this point only my code is modified (convert texts from utf8 to widechars,
> use minibidi, convert back)
a little inefficient - but ok. as it can't just do 1 char at a time (or current
and previous char for kerning) as it can do in western left-to-right text, or
even asian text).
what's the licensing on that minibidi code?
> (as of now, libfribidi only handles 1), and 2) is said to be tested in cvs)
>
> 3) when displaying the texts, some chars are only accents and need to be
> placed on the preceding letter and not after (like short vowels, or chadda)
aaah yes. the combining :)
> to get this done is only possible by modifying evas
>
> for exemple
> i changed the evas_font_draw.c like this :
> chr_x = (pen_x + (fg->glyph_out->left << 8)) >> 8;
> chr_y = (pen_y + (fg->glyph_out->top << 8)) >> 8;
>
> if (gl == 1617) chr_x -= fg->glyph_out->bitmap.width; <-- line added
>
> ......
>
> if (gl != 1617) { <-- line added
> pen_x += fg->glyph->advance.x >> 8;
>
> here 1617 corresponds to the chadda char
ouch! that is a bit evil. i mean cool - it works, but something just smells
wrong. what is there is more than one such character? it feels wrong to have
such special case hacks. is there not some way to ask freetype if this is such
a sepcial char (the font will tell us what chars are such special chars) ?
> and it works !
>
>
> so, now are my questions :
>
>
> would it be a good idea to add support for arabic text (and hebrew, and
> complex languages) ?
absolutely. i stand fully behind such support. i think it's a great idea. i
just have not had the time/knowledge or "kick in the bum" to do it. i have
ensured evas supports asian languages though (i live in tokyo - so well... kind
of comes with the territory). so don't interpret silence on this as "go away" -
it's my mail backlog! :(
> which functions would need to be modified ?
> (are for example some functions returning string lenghts ?)
evas_font_draw.c and evas_font_query.c definitely. then the
evas_object_textblock.c needs fixing up - and that is one big fat complex
bugger as it is a full text layout and formatting/wrapping engine.
> how is text internally encoded ? widechars or locale dependent ?
evas stores everything as utf8 - it is decoded at draw (and query time) into
ints so each glyph is a unicode codepoint. evas ONLY handles utf8 as the
encoding - it expects all apps to provide text to it in utf8 encoding -
irrespective of locale encoding.
> would it be acceptable to include minibidi source code or should we wait for
> libfribidi ?
that depends on licensing - as above :) also on the code, code size, complexity
etc.
> ....
>
> all comments welcome !
>
> Wagner Frederic
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
