Fwd: Re: Pango portability (or rather the lack of it)

From: Hubert Figuiere (hub@nyorp.abisource.com)
Date: Thu Apr 25 2002 - 04:34:38 EDT

  • Next message: Hubert Figuiere: "Fwd: Re: selections and combining characters"

    ----- Forwarded message from owner-abiword-dev@abisource.com -----

    To: "Tomas Frydrych" <tomas@frydrych.uklinux.net>
    Cc: abiword-dev@abisource.com
    Subject: Re: Pango portability (or rather the lack of it)
    References: <3CC6DB11.5706.2C86B8@localhost>
    From: Havoc Pennington <hp@redhat.com>
    Date: 24 Apr 2002 22:03:37 -0400
    In-Reply-To: <3CC6DB11.5706.2C86B8@localhost>
    Message-ID: <y5wn0vs8rgm.fsf@icon.devel.redhat.com>
    Lines: 26
    User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii

    "Tomas Frydrych" <tomas@frydrych.uklinux.net> writes:
    > So, the bottom line is that Pango only really works on Unix. Until
    > this changes, it is not suitable for use in AW.
    >

    So you're going to reimplement over a year of debugged work by an i18n
    expert and a bunch of contributors with language-specific expertise,
    instead of working on fixing up the win32 port, which needs to be done
    for GTK itself anyway?

    And end up with a document editing area with different behavior
    from your entry boxes in terms of selection, delete keys, etc.

    This just doesn't make sense to me. I don't think you understand how
    complex it will be to implement all this, or how hard it will be to
    match the user-visible behavior that Pango presents (it will be easy
    for Europe of course, but not for the hard languages).

    If the Pango release cycle doesn't sync with yours then cut-and-paste
    Pango for a while and keep an internal copy (ideally as pristine
    tarball + namespace sed job + patch set). But there's no reason to
    redo the work.

    Havoc

    ----- End forwarded message -----

    This archive was generated by hypermail 2.1.4 : Thu Apr 25 2002 - 04:34:42 EDT