[Fresco-devel] Babylon Strings

Hi!

Nice to finally see some more activity on f-devel again!

I have been thinking about how to handle Strings in Babylon for a while
now and I hope to have finally come up with something that might
even work for a change;-) Please comment.

Let me explain the problem first:

We have a C++ Unicode library called Babylon (depends on Prague, the
POSIX wrapper only, feel free to use it outside of Fresco) and I
want to handle as much as possible of the sticky i18n issues we get
from using Unicode in this library. Currently I'm thinking about
how to handle bidirectional textflow in a way easy to understand
for Babylon users (aka. developers using Babylon).

Unicode specifies that you store the characters in the sequence
you type them. This is called the memory order. On the other hand
you might need to map this memory order to a visual order when
displaying: If you have a hebrew-only text (hebrew is written from
right to left) all you need to do is render the last character in
memory order first, then the one before the last, etc. If you have
a text containing a mixture of english and arabic then this mapping
gets very hairy! I want to hide this complexity from the developer
using Babylon. Since the Fresco server needs to see visual ordered
strings when rendering we cannot just pretend there is no visual
order and forget about it.

So I thought it would be nice if Babylon's String class had an
interface like this:

class String
{
  public:
    ... usual string stuff ...

    String memory_order(); // Get the corresponding memory-ordered String.
    String visual_order(); // Get the corresponding visual-ordered String.

    ...
}

This way a developer can get both kinds of ordering and work with
both in the way he is used from the std::string class (plus some
Unicode-specific extra members). The mapping process is completly
hidden.

What do you think about this idea so far?

The problem comes with a memory-efficient implementation of this
idea:-)

You need a String class that can have two different implementations,
depending on the order the String is in. You further need to be able
to couple the visual-ordered String with the memory-ordered String
so that updates to one effects the other, too. I attached a little
UML-sketch about how this could be done.

What do you think? Is this what we need at the Babylon level of the
design? Stefan thinks we only need the memory-oder, but then I
understood him to argue from a fresco application developer's point
of view. I agree with him that somebody developing an application
for Fresco shouldn't need to bother with visual orderings, but I
want the bidir handling in Babylon (that's where it belongs IMHO)
and since berlin (our implementation of the fresco display server)
needs the visual order we need Babylon to export this information
in some way.

-- 
Gruss,
Tobias

------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/F9GBv0FZW3NyoqURAtz4AJ9fggNs766biWFAMS5VE3wWrY9fKACeL4oy
Res7eji3woDxBssqYzfAytY=
=afyM
-----END PGP SIGNATURE-----