From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Thu May 09 2002 - 05:14:15 EDT
Hi Paul,
> 1. native, non-bidi ... the well-tested code that everyone uses now
> 2. bidi ... some testing, not enough use 3. Pango-based ... to be
> written and/or ported as needed
OK, I see I need to explain the relationship between #1, #2 and #3.
#2, the bidi code, is not some monster genetically unrelated to #1,
the non-bidi code. #2 does everything that #1 does, plus the extra
bidi processing. In fact most of the time the bidi code is basically a
carbon copy of the non-bidi code just with some extra logic
plugged into it, often just an extra if(LTR) {} else {}. For left-to-right
languages it behaves identically to #1, because the code is virtually
the same, i.e., the if(LTR) branch is usually just a copy of the non-
bidi code in the #ifndef BIDI_ENABLED #endif section.
#3, the Pango stuff, is not a replacement for #2, it is replacement
for the home grown shaping engine that resides withing #2. The
actual bidi layout code will stay in place for the time being for
reasons we have discussed at length in the Pango thread.
> Most of the developers we hope to attract will only care about those
> languages, and we *definitely* want them working on HEAD. Yet it
> sounds like you're talking about *removing* that proven code
> immediately. Why?
Because the bidi code is a superset of the proven non-bidi code,
and the whole scenario is a maintanence nightmare. I would be
surprised if there would not be some extra bugs as a result of this,
but I doubt that they will be too many. I personally do not use any
other version of AW than the bidi one and I have not come across
any bidi-only problems since the start of the year. If you look at the
bugzilla, you will see that there are only a few bugs reported for the
bidi build (not necessarily because no-one tests it, there is now a
number of deticated testers), and AFAIK all of them are related to
RTL languages.
> While it may make life easier for Pango development to force all
> developers to live through that transition as it happens, it makes
> *much* more sense (for other developers) to *not* switch everyone over
> until Pango is further along.
Just to make sure we understand each other, I am not talking
about switching everyone to Pango, you are quite right, we are
nowhere near that (we have hardly started). I am talking about
switching everone to a somewhat expanded version of the proven
existing code. This change will not break the tree, nor will it reduce
the functionality for the languages supported by the non-bidi build
(in fact it will enhance it as the bidi build is more Unicode
compliant).
I hope this explain things.
Tomas
This archive was generated by hypermail 2.1.4 : Thu May 09 2002 - 05:21:52 EDT