[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BiDi plugins] So far I talked in the air, now there is some actual , code which will , be warmed by flames!
Hello Guy and Dov,
> i see you already implemented the 'null' plugin interface. that's very
> good.
Sorry for the nitpicking but I want to use clear terminology.
What I defined is 'plugin interface'.
The 'null' plugin is a 'plugin', which implements one side of the 'plugin
interface'. The important 'plugin' for Hebrew and Arabic users is the
'bidi' plugin.
I want to have as many Linux applications as possible to implement the
other side of the 'plugin interface'.
> what i would suggest to do next, is split the effort. there is a need for
> 2 programmers:
>
> 1. one that will implement the 'bidi' interface - i'd suggest taking off
> dov grobgeld's code, and using it there. this would require that dov's
> source code has an interface with which your interface can interact,
> without the need to modify his source code. if such an interface is
> missing, then it should be added, and dov wold be kind enough to
> incorporate it into his fribidi library.
Some things are missing from Dov's implementation:
1. Line breaking code - must be integrated with his code, cannot be added
as afterthought. It should support both level 0 and level 1 of plugins
(level 1 support means, for Dov, that for each character he'll call a
callback which will give him its width in pixels and from the
accumulated width he'll decide where to break the line).
2. Support for incremental work (i.e. if a string was modified in the
middle, then re-order it only from the point of modification onwards).
I think that the best person to make those changes is Dov himself.
In addition to the above changes, it would be nice if Dov could define
configuration options for his procedure - so that if someone doesn't like
Hebrew Windows behavior, he can change the plugin's behavior:
1. Dov mentioned that he made P1 rules (ES and CS) work only if the span
of the ES or the CS is 1, the same as in Hebrew Windows. This is
something which could be turned into a parameter (DISCLAIMER: I didn't
look into the implications of this in detail, as far as I am concerned
- this might be useless).
2. The classification of characters could be loaded from a configuration
file rather than be built-in.
3. The rules for rendering Hebrew written vertically (such as in
billboards) are somewhat different from those applying to Hebrew
written horizontally. It would be nice to be able to choose which set
of rules to follow according to an configuration option.
After Dov has implemented the above enhancements, I'll do the rest of the
work of implementing the 'bidi' plugin.
> 2. another programmer to actually take pico's source code and integrate
> your library with this source code.
>
> i'm willing to do either part. tell me which one you choose, and i'll do
> the second part. dov already chose implementing the 'bidi' algorithm
> itself, and i'm am sort of "vulenteering" him to continue what he started
> :)
Guy, you are most welcome to work on pico.
If possible, please work on version pine3.96_heb2.07 (the same version
which I downloaded and compiled under Linux). Unless you have good
reasons to do otherwise, please:
1. When finished, package your work in the form of a patch to
pine3.96_heb2.07, and then try it on the most recent version of pine.
2. In the Setup part of pine/pico, allow the user to select a default
plugin.
3. Add to pico a command to select/edit a plugin+configuration from a list
(to be loaded from a file, like the addressbook).
4. And of course, modify the code for refreshing the display so that it'll
work with the plugin rather than do everything by itself.
When doing (4) above, you'll in effect be debugging the interface. So I'd
like to follow closely this work and modify the interface definition if
anything proves to be missing or awkward.
> dov - are these possible requirements o.k. with you?
> also, can one downlod 'glib' without downloding the whole 'gtk'
> distribution? which version of 'glib' is required for use with
> 'fribidi'?
The version of 'glib' which got installed in my RedHat 5.1 out of the
box - worked OK for me. So I agree to assume that 'glib' is available in
all modern Linux installations.
> omer - is there any objection to making 'glib' a requirement for using
> your library?
I prefer not to require anything beyond Dynamic Loader as a condition for
using my plugin interface. Also, client software (such as pico) should
not need additional libraries due solely to the plugin interface
implementation. But it is allright if an individual plugin utilizes any
libraries it wants to.
This is because I'll want the plguins to be available not only for Linux
but for as many operating systems as possible, to which FSF GNU software
was/is/will be ported.
> as to possible flamers: i'd say that this is a damn good programming
> excersize, even if it leads to nothing: at least for myself, since i use
> pine/pico for handling email, i have a personal interest in seeing this
> work even for these programs only.
Thanks.
Even if the plugin project goes nowhere, we'll have at least one thing:
pine/pico, which knows to handle logical Hebrew letters and therefore can
interoperate with M$-Outlook.
--- Omer