Re: fribidi & arabic shaping

[Nadim Shaikli <shaikli at yahoo dot com>]

--- "Chahine M. Hamila" <mch at chaham dot com> wrote:
> Nadim Shaikli a *crit :
> 
> > > If this is not a question of feasibility and just a desirable option, I
> > > find no merit in it. I understand that asking authors to adopt FriBiDi
> > > and Pango is more difficult than requesting one or the other.
> >
> > It is both - feasible in that you get all applications that have fribidi
> > in them already supporting arabic shaping for free (which is desirable).
> 
> I thinnk I see where you're getting at, but I think there is more than that
> Nadim.
> 
> Let's suppose we have an application that already uses fribidi and not pango.
> So,
> putting aside the square arabic option, we want it to shape without changing
> anything?
> If I understand you correctly then, in fact, that would still imply other
> changes
> in any case.
> For example, supposing a call to the ordering function doesn't order only but
> shapes as well, it would mean the string would be encoded in a glyph-shapes
> form,
> not in any standard encoding.
> This would mean many things.
> Assuming your output is 8-bit (i.e. a second call is made for a unicode to
> 8-bit
> char encoding conversion is made) it would mean the conversion function would
> have
> to be aware of what font you are using, so you would have to decide for one
> font
> and no other (more or less, I'm simplifying here) for all fribidi
> applications.
> Now assuming you are using a wide char unicode encoding, it would mean you
> are
> probably going to use the upper shaped glyphs, and have suitable fonts for
> that.
> But there's more than that. All this is ok for rendering, but would be out of
> question for all other underlying operations, from saving data to making any
> character-dependant string manipulation, so you would probably have to modify
> your
> code anyway. Which then would make it easier to include Pango.
> See the point? Modifying the ordering layer is simply not enough to have
> shaping
> automatically included in the apps that already support it. The reordering
> acts
> partly on the logical level, while the shaping acts at, and must act only at,
> a
> very strictly visual level.
> See the point?

I think most applications will simply leave the font manipulation post any
output from Fribidi (or any other Bidi) and what this shaping would amount
to is the replacement of the glyph encoding (simple as that) - that's what
I would do if I had to implement a shaper and I would certainly not fool
(as I think fribidi would not) with any font calls.

I believe both shaping and reordering act strictly on a visual basis (if
they didn't we'd be in DEEP trouble :-)

In short what happens today,

 1. string_A = application produces string (screen-line buffer)
 2. out_fri = fribidi(string_A, other stuff :-)
 3. out_vis = someone else graps out_fri and does shaping substitution
 4. out_vis goes to display engine (and font calls, scaling, etc)

It would be ideal to put step 2/3 above into one - that's all.  Its definitely
not as complicated as you might think -- its about 60 lines of code.

 - Nadim


__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/