Re: 32-bit UT_UCSChar (2)

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Thu May 02 2002 - 04:07:58 EDT

  • Next message: Martin Sevior: "Abiword in (unhacked) Evolution."

     --- Tomas Frydrych <tomas@frydrych.uklinux.net>
    wrote: >
    > I cannot recall if I sent a message about this to
    > the list or not ...
    >
    > I am working on the 32-bit UT_UCSChar, and should
    > have it
    > finished over the weekend, when I plan to commit
    > this (unless there
    > are serious objections).
    >
    > There will be two main changes: (1) change of the
    > definition of of
    > UT_UCSChar to 'unsigned int'; (2) I will add a new
    > type
    > UT_GrowBufElement == 'int'. The latter type will be
    > used by the
    > UT_GrowBuffer class. The reason for this is that in
    > the current
    > implementation the grow buffer is used both for
    > storing
    > UT_UCSChar strings and character width strings,
    > currently
    > UT_uint16; in order for this to work the width will
    > have to be also 32-
    > bit ints (and becase Pango provides widths as signed
    > ints, I want
    > them stored as 3-bit ints anyway).

    What do you mean by "3-bit ints"?

    > This means for all platforms the methods in the
    > graphics classes
    > which use character widths will need change from
    > UT_uint16 to
    > UT_GrowBufElement. I will do win32 and, possibly,
    > Unix. Apart
    > from this, there might be other occassional changes
    > where
    > UT_uint16 was used when UT_UCSChar should have been;
    > I found
    > one instance on win32 so far.
    >
    > The other issue which will need addressing is the
    > interface to the
    > native text drawing calls, such as on win32 which
    > only uses 2-byte
    > characters.

    These calls will have to pass strings that have gone
    through iconv. The other OSes all use UTF-8 AFAIK so
    they can't be used directly either.
    It might be tricky on Win32 knowing when to convert
    to UCS-2 and when to UTF-16. For starters it's
    probably easiest to always convert to UTF-16.
    If calls take a single character (byte/word/int) and
    not a string I'm surprised. I don't know how you
    would draw a UTF-16 character this way on Windows.
    I don't think it ever makes sense to draw single
    characters anyway since in the general case context is
    needed.

    Andrew Dunbar.

    > Tomas

    =====
    http://linguaphile.sourceforge.net http://www.abisource.com

    __________________________________________________
    Do You Yahoo!?
    Everything you'll ever need on one web page
    from News and Sport to Email and Music Charts
    http://uk.my.yahoo.com



    This archive was generated by hypermail 2.1.4 : Thu May 02 2002 - 04:10:08 EDT