On Wed, May 26, 2004 at 04:47:29PM +0100, Muhammad Alkarouri wrote: > > 2. miniBidi must quickly comply/conform to the entire > > standard > > 'Must'? Hopefully. We have an excellent record on the 'quickly' thing. > Please give an estimate of time (either core or miniBiDi maintainer). Must, yes. Quickly -- your mileage may vary ;) > miniBiDI is to remain simple and compliant at the same time? or one of these > conditions can be somewhat sacrificed? > As Ahmed said, compliance is the priority. > .. assuming that we can choose for them if they passed the deadline. > You mean really people like CUPS will hesitate to choose for some time and then > we will decide for them? No, CUPS have clearly stated that FriBiDi is not for them. We give FriBiDi time to persuade them otherwise. If this does not work then we use miniBiDi as they have no issues with the license. > Let this be clear. If a project wishes to use miniBiDi (due to license issues > or some other reasons) this will get us in a number of problems: > - They use miniBiDi And that is a problem? PuTTY uses miniBidi.. ? > - miniBiDi is either conforming or not. If it is not, we will have a large > number of bugs related, which will keep software not compliant for ages to > come. This is a no-no. Hence the "must". > - If miniBiDi is compliant, fine and good. Notice that this means we will have > to maintain it: squash any bugs that appear, and tracking the Unicode standard > which will probably change (slowly) from time to time. > Naturally. I/We hope that Behdad and company would be a helping hand to ensure that miniBiDi is compliant (as he and Roozbeh have always been ultra-nice ;) > In other words, I don't like this decision, as it is bug-prone. Either we > support FriBiDi and forget about miniBiDi altogether, or we are prepared to > give full status, including maintaining and updating, to miniBiDi. Don't like it? It is not a matter of liking or not. You either use miniBiDi or forget about bidi support in applications such as putty and cups. The only other solution would be to write alternatives to cups and putty and then use fribidi -- and that wouldn't make any sense. So, it's not really an issue of what your pleasure would be today.. it's a situation where we have little choice in. > I would also add my support to this last statement. FriBiDi's two problems now Finally! Some support.. ;) > are its license and lack of shaping. Though the issue of licensing does not > bother me and I have a whole set of arguments for L/GPL, the lack of shaping > remains an issue. > (I know, Behdad, use BiCon's..) > The problem with the GPL is that it only swings one way, whereas no one can ever have a problem with an MIT or BSD type of license (in terms of including its source in their application/library). These licenses swing both ways and that is precisely what is needed for something as critical as bidi. You can love L/GPL all you want (I personally don't like them one bit) -- but personal preferences aside, the reality is, the GPL is hampering efforts and forcing us to re-invent the wheel needlessly. Regards, -- ------------------------------------------------------- | Mohammed Elzubeir | Visit us at: | | | http://www.arabeyes.org/ | | Arabeyes Project | Homepage: | | Unix the 'right' way | http://elzubeir.fakkir.net/ | -------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature