[Fribidi-discuss] fribidi & arabic shaping

[Nadim Shaikli]

On Sat, 23 Mar 2002 11:00:14 -0000
  "Tomas Frydrych" <tomas frydrych uklinux net> wrote:
> 
> I want restate the point I made a couple of days ago which was not 
> picked up. A proper shaping library should be able to do the 
> shaping for the entire Unicode space, not just Arabic.

I agree in the context of a shaping library; but with Bidi (and fribidi
in particular) the only three languages being addressed, at this point,
are Arabic, Hebrew and Farsi and as such adding whatever small fragments,
again __optionally__, still seems to make sense to me.  In other words, if
Chinese mandarin requires shaping (which I don't think it does, but just
as an example) then I would certainly not propose or even suggest adding
Chinese shaping to fribidi since Chinese (again, just as an example) does
not require Bidi.

> Now, I can use FriBidi for all of these sets, legacy or not, but if we 
> add an Arabic-only shaping engine on the top of it, I will still need 
> some other shaping engine beside it that will do the job for the non-
> legacy code pages too, leaving the Arabic-only shaping engine 
> superflous.

Agreed.  For the record I'm all for adding whatever "extensions" for all
Bidi languages that have shaping requirements.  As for this being superfluous,
you are absolutely correct - it would be if a shaping library existed in
our current time-frame.  In other words, since a lightweight shaping library
doesn't exist and we could add one optionally (until one comes about), we
can still support a couple of the Bidi languages with very little (if any)
pain.  Having a lightweight RTL shaping only library in its own right seems
rather silly and would certainly not be adopted by anyone sans fribidi.

>                  Conditional compilation is not a good solution here, 
> because I will possibly be linking against FriBidi already installed 
> on the users system, rather than providing my own version of 
> FriBidi with the application.

There's been one interface change already (from my understanding) which
leads me to believe that some checks need to be in place to account for
legacy code (anyways) to verify the user's fribidi version and API.  This
suggestion would fit into that same mold or can even wait until the next
interface change is called for :-)

> So, yes, I want a good Arabic shaping engine based on the 
> presentation forms to use with AbiWord in very near future, but I do 
> not want it loaded just because I linked against FriBidi, because 
> one day I expect to do the shaping using the FreeType Layout 
> library, and I will still then need to use FriBidi to do my bidi layout.

Very true and thus the optionality of this (ie. disable it from the get-go
if that fits the application's needs).  If AbiWord decides to adopt Pango
(and it should :-) then this suggestion, if adopted into fribidi, wouldn't
alter anything in AbiWord's treatment of the world.


Also,

On 03/23/2002 14:26:48
  Tzafrir Cohen wrote:
> 
> On Sat, 23 Mar 2002, Owen Taylor wrote:
> > Well, not yet.... but wouldn't it be easier to help add these
> > capabilities to Pango rather than starting for scratch?
> > I'm not saying that Pango is the solution to everyone's layout
> > problems, but "Pango doesn't work on all platforms, therefore
> > I'm going to write something that does work on all platforms"
> > is just silly. "
> 
> A claim that may make sense is:
> 
> pango is an overkill because it is too general.
> I'll try to write something new just for shaping of arabic and then I
> have better chances of making it work on other platforms.
> 
> Is that correct?

If that statement is made in the framework of fribidi, then that's what
I'm humbly attempting to point out but not in the context of just Arabic;
I'm thinking in the context of all Bidi languages that require them
(Arabic, Farsi and Hebrew at this point) - its inclusion, yet again, to
be done on an optional basis.

To recap, the reason any application would include Bidi (and fribidi) at
this point is to support Farsi, Arabic and Hebrew, so why not extend it
slightly for those languages to really make it complete by optionally
including the required shaping.  If a shaping library picks up steam and
becomes a reality then disable that optional feature within fribidi and
simply use this newly created shaping library and the Bidi aspect of Fribidi.
If an author, on the other hand, opts for Pango's extensive support today,
then great; given enough non-hardcoded options, the authors will make the
best decision regarding their applications.

Regards,

 - Nadim


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