Fwd: Re: Pango?

From: Hubert Figuiere (hub@nyorp.abisource.com)
Date: Sun Apr 28 2002 - 05:49:34 EDT

  • Next message: Hubert Figuiere: "Fwd: Re: Pango?"

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

    To: "Tomas Frydrych" <tomas@frydrych.uklinux.net>
    Cc: abiword-dev@abisource.com
    Subject: Re: Pango?
    References: <3CC6A002.27673.7EFD25@localhost>
    From: Havoc Pennington <hp@redhat.com>
    Date: 26 Apr 2002 11:12:48 -0400
    In-Reply-To: <3CC91330.29562.26DDB8@localhost>
    Message-ID: <y5whelyqyrz.fsf@icon.devel.redhat.com>
    Lines: 69
    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:
    > > > No, FreeType is independent of any system font mechanism; it
    > > > parses the font files and gives you the glyphs as bitmaps.
    > >
    > > You really must use fontconfig on UNIX though to get the list of
    > > available fonts, font names, etc. though. I don't think shipping a
    > > custom set of fonts with AbiWord is really any good at all for users.
    > > We're getting GTK, Qt, Mozilla, everything on fontconfig, please don't
    > > create exceptions... things are such a mess right now and fontconfig
    > > is such a good idea...
    > The problem we have with fonts on Unix is (1) we can only use
    > scalable fonts

    Pango/Xft only offers scalable fonts right now. Owen believes that
    fixed-size fonts break the font API.

    With fontconfig/Xft2 this is just a function of the font configuration
    file (you can optionally have it include the traditional X pcf fonts,
    but on the client side; we will never be using server-side fonts).
    Owen's view is that the font config file should contain only scalable

    Yesterday I pointed out that we have no usable scalable fonts for
    terminals, and he suggested that we might need to put in a couple of
    the pcf bitmap fonts, renamed something like "Foo" -> "Foo
    Terminal". But if the font is called "Foo Terminal" it should be
    pretty obvious to users that they shouldn't choose them for a word
    processor document. (Apparently Windows did this same thing for a
    while, had a couple of fixed-size terminal fonts hanging around after
    moving mostly to TrueType.)

    If doing that breaks AbiWord badly I'm sure we can figure out some
    sort of hack to avoid the problem. It's just a temporary issue until
    we can get a truetype terminal font that doesn't suck in any case.

    > (2) we have to be able to use the font on screen and
    > to be able to generate PS output with it.

    Keith Packard argues that the right way to do this is to only ever use
    client-side fonts (no server side fonts), even on old/legacy X
    servers. He's the designer or codesigner of the original server side
    font system, too, IIRC. Anyway, so he is writing Xft2/fontconfig,
    trying to get everyone to use it, and basically the free software
    community is just going to deprecate server-side classic X fonts.

    FWIW GTK+ and Red Hat are both enthusiastic about this approach, and
    Qt is also using it. Even xterm has been patched. So server-side fonts
    will soon be of interest only to Motif developers. Expect to see a
    fontconfig/Xft2 version of Pango in a couple of months. (Public pango
    APIs won't be changed in this transition.)

    > Most fonts installed on a typical Unix do not fall into this
    > category, so we either ship our own set of fonts, or develop a
    > mechanism for filtering unsuitable fonts out. The former is what we
    > do, the latter is what we should do, but we need to take it one
    > thing at a time.

    I don't think the requirement to print is unique to AbiWord; it's
    shared by most apps. So the general idea is to filter these fonts on
    the fontconfig (or other system on win32) level, and use only
    client-side fonts so we always have them available to print with.

    Then all apps will Just Work.


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

    This archive was generated by hypermail 2.1.4 : Sun Apr 28 2002 - 05:49:37 EDT