[Fribidi-discuss] (Justified?) compilation warning

[Shachar Shemesh]

Behdad Esfahbod wrote:

>Well, I must confess that it was a real bug report.  Thank you 
>Shachar.
>
>  
>

As opposed to so far, where I have just been moving my lips and no 
useful information came out ;-)?

Back to the useless yapping, though. I have had close to no time to work 
on anything during your holiday. I have been thinking about several 
methods for supporting more than one encoding. I will suggest them here 
for discussion. I am using SHOULD, MUST, SHOULD NOT, MUST NOT with the 
RFC semantic:

   1. configure parameters - when running ./configure, you specify what
      character length you want to support, and the include files are
      generated accordingly. The function names SHOULD be unique (for
      example, by appending "16" to the names), as do the library names.
   2. Compile all functions to the same library - make will perform
      several runs on the same code, passing different "-D" flags, thus
      generating code for all different encoding types. The functions
      now MUST have different names, or the resulting library will not
      be able to link to anything (will conflict with itself). The
      include files MUST be includeable by an extrenal program by the
      program specifying the relevant defines. A sample program:

#define FRIBID_CHAR_WIDTH 32
#include <fribidi.h>
#undefine FRIBIDI_CHAR_WIDTH
#define FRIBIDI_CHAR_WIDTH 16
#include <fribidi.h>

You can see that part of the requirement is that a single program can 
use several interfaces of fribidi from the same file. Alternatively, we 
can use:
#include <fribidi.h>
#include <fribidi16.h>

and have the makefile generate these files in some way.

       3. Support all encoding lengths using the same code - The 
suggestion was already made. Use a preprocessor to mark the character 
begining and end, and have the reordering code work on a byte by byte basis.

The way I see it, these are the cons and pros:
Option 1 - probably easiest to carry out. Creates extra work for 
packagers. Efficient code for both 16 and 32 bits characters.
Option 2 - More work on the make env. Probably not more work on the 
sources, though. Enabling this option does not prevent anyone who really 
wants to from using option1 (i.e. - a configure option that will only 
compile one flavour). Such a direction, though, will probably cause 
inconsitancies between distributions regarding what is and what is not 
available for the fribidi package.
Option 3 - The most ambitious one. Probably not that hard to implement, 
but you lose static type checking. You are also losing efficiency for 16 
and 32 bits. This also requires the greatest interface changes (need to 
characterize the string with a different function). On the other hand, 
with this option you can also eazily support all encodings, not just the 
unicode ones. Want to directly reorder iso-8859-6? No problem. How about 
Japanese? No problem.

I think going for option 2 for 16 and 32, and option 3 (perhaps at a 
later date) for 8 bit encodings (UTF-8 and all the rest) is the best 
long term solution. Whether we recommend packaging this seperately or 
not is another question (I think not, but that's my opinion).

                Shachar