Hi list, Like I mentioned ealier last week, I intend to add BiDi support to WINE. There is a library called fribidi (http://fribidi.sourceforge.net/) that does a pretty good job, and seems exactly apropriate for this task. I have two questions: A. What are my chances of getting a patch of this magnitude incorporated into the tree. The library is not particularily big, but includes a set of unicode translation files that are automatically generated from the unicode standard. It seems that WINE holds similar files itself, for similar purposes. I have not yet checked whether they conflict, and if they do, whether this conflict is resolvable. B. The library is under the LGPL license. I understand that some of the WINE tree is under the same license, while other parts are under the X11 license. Can someone please comment on the implications of such a move? What things do I need to take into consideration? I would also like to solicit the help of any Arabic speaking developer in this process. I know some of the basic concepts behind Arabic writing, but I am not nearly fluent enough to provide bug free code. Shachar
On Sunday 24 March 2002 16:51, Shachar Shemesh wrote:
Hi list,
Like I mentioned ealier last week, I intend to add BiDi support to WINE. There is a library called fribidi (http://fribidi.sourceforge.net/) that does a pretty good job, and seems exactly apropriate for this task. I have two questions:
Shachar, the problems are two fold actually: 1. As it stands now - you can't even see hebrew because, simply put, the fonts rendering doesn't support it - run Word Viewer with a hebrew document and see what I mean. 2. The hebrew keyboard is not supported at all, plain and simple. Fact is - if you use the following command to enable hebrew/english switching: setxkbmap -option grp:switch,grp:shift_toggle,grp_led:scroll il Then not only you won't get hebrew support (or anything which resembles hebrew), but as soon as you'll press the SHIFT key (like doing @) all the letters will become caps lock enabled (meaning - only big letters, like the shift key is stuck), and you'll have to switch several times, type random text, switch again and you'll get your keyboard bad... Adding Bidi support (or even full unicode) is a huge piece of work to do. If you want to add it - then I salute you and hope you'll make it.. Hetz
1. I tested a small UNICODE program I wrote that used DrawText, and it printed Hebrew just fine on my system (Debian SID, don't know what version of WINE). It didn't print Hebrew with the ANSI version, but that is probably just a codepage problem, as ExtTextOutA simply converts the string to unicode and calls ExtTextOutW. 2. Havn't tested that yet, but I suspect it's a similar problem. How do you do it for multi-locale keyborads of other types (german, british, etc)? Shachar
On March 24, 2002 09:51 am, Shachar Shemesh wrote:
Hi list,
Like I mentioned ealier last week, I intend to add BiDi support to WINE. There is a library called fribidi (http://fribidi.sourceforge.net/) that does a pretty good job, and seems exactly apropriate for this task. I have two questions:
A. What are my chances of getting a patch of this magnitude incorporated into the tree. The library is not particularily big, but includes a set of unicode translation files that are automatically generated from the unicode standard. It seems that WINE holds similar files itself, for similar purposes. I have not yet checked whether they conflict, and if they do, whether this conflict is resolvable.
Can you perhaps test in configure if fribidi is available and if so, make use of it, if not, do not compile in BiDi support? This way you don't have to include the entire fribidi stuff in Wine, and the patch would not be as big:) However, this brings another questions: should we separate the Unicode stuff out of Wine, could it be usable by the fribidi stuff as well? Maybe Mozilla, and other projects? It's not that big, but it seems everybody and their brother have their own copy of the stuff.
B. The library is under the LGPL license. I understand that some of the WINE tree is under the same license, while other parts are under the X11 license.
No, the WINE tree is in entirety under LGPL, so linking against the fribidi library is fine. There are talks of starting an X11-licensed tree, when it becomes available, it's gonna be their call if they consider it OK to link against fribidi (this, of course, provided you license your code under X11 as well). -- Dimi.
First, I want to mention that I was contacted by a group who has been working on the same project for some time now, and we may simply merge our efforts (they are, quite obviously, much further ahead than me). Assuming that doesn't work out, however.... Dimitrie O. Paun wrote:
On March 24, 2002 09:51 am, Shachar Shemesh wrote:
A. What are my chances of getting a patch of this magnitude incorporated into the tree. The library is not particularily big, but includes a set of unicode translation files that are automatically generated from the unicode standard. It seems that WINE holds similar files itself, for similar purposes. I have not yet checked whether they conflict, and if they do, whether this conflict is resolvable.
Can you perhaps test in configure if fribidi is available and if so, make use of it, if not, do not compile in BiDi support? This way you don't have to include the entire fribidi stuff in Wine, and the patch would not be as big:)
That sounds like the most reasonable suggestion. This way we can automatically benefit from new versions of libfribidi, and the porting effort will be minimal. I'll be frank and say that my main concern is that standard packagers (RedHat) will not include it if it will be configured this way. I guess, however, that the meaning of "Free software" is to let the packager have the freedom to ship the inferior product. More concerning is the fact that, as Alexandre said, fribidi is UTF-32, requiring unnecessary conversions (all Arabic and Hebrew chars fit into UTF-16 without surrogates).
However, this brings another questions: should we separate the Unicode stuff out of Wine, could it be usable by the fribidi stuff as well? Maybe Mozilla, and other projects? It's not that big, but it seems everybody and their brother have their own copy of the stuff.
Fribidi does have, to some degree, a unicode implementation. I don't feel aquinted enough in the surrounding details to give an informative opinion, however.
(this, of course, provided you license your code under X11 as well).
Hard for me to answer at this stage, but I am not inclined to. Shachar
Shachar Shemesh <wine-devel(a)sun.consumer.org.il> writes:
A. What are my chances of getting a patch of this magnitude incorporated into the tree. The library is not particularily big, but includes a set of unicode translation files that are automatically generated from the unicode standard. It seems that WINE holds similar files itself, for similar purposes. I have not yet checked whether they conflict, and if they do, whether this conflict is resolvable.
You don't want to include the full library in the tree of course; there is already a bunch of unicode stuff in libwine_unicode so what you probably want to do is take algorithms from fribidi and merge them into libwine_unicode. The unicode tables in there could easily be extended to add the required information; I can help you with that if necessary. I doubt you could use fribidi directly anyway since AFAICS it uses 32-bit Unicode chars, while Wine needs 16-bit chars.
B. The library is under the LGPL license. I understand that some of the WINE tree is under the same license, while other parts are under the X11 license. Can someone please comment on the implications of such a move? What things do I need to take into consideration?
The whole tree is now under LGPL, so it's not a problem to merge code from fribidi wherever you need. -- Alexandre Julliard julliard(a)winehq.com
participants (4)
-
Alexandre Julliard -
Dimitrie O. Paun -
Hetz Ben Hamo -
Shachar Shemesh