Re: Pango?

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Wed Apr 24 2002 - 11:50:50 EDT

  • Next message: Andrew Dunbar: "Re: User's guide translation"

     --- Tomas Frydrych <tomas@frydrych.uklinux.net>
    wrote: >
    > > Andrew Dunbar:
    > > Does it actually render all 5 characters into the
    > one
    > > character cell or does it need to map them to a
    > > precomposed character?
    > It lays the 5 characters over each other.

    Good. This will work for existing Vietnamese.

    > > Cool! Does it support the Arabic vowels?
    > No, I have no knowledge of Arabic, the only stuff I
    > implemented is
    > the consonant shaping and support for 2-char
    > ligatures. I would love
    > to do more, but it is beyond my abilities.

    I think Arabic vowels get complicated when there are
    also exotic ligatures present. I have no idea how to
    draw two vowels around a ligature of two consonants!
    But I think Pango does (:

    > > Maybe Syriac.
    > Unfortunately, Syriac is defined purely semantically
    > in Unicode, the
    > shaping is delegated to font renderers, which is one
    > reason why we
    > really need OpenType support.

    Yes. Same with the Indic languages. OpenType alone
    doesn't make it "just work" either.

    > > Greek has a final form for Sigma but I
    > > read somewhere that this is usually handled
    > specially.
    > The Greek data is in the tables, but I have no idea
    > what a Greek
    > user expects. (I got into trouble because of
    > automatic shaping for
    > Hebrew; the normal Israeli user does not expect
    > that, so I had to
    > add a checkbox into preferences and it is off by
    > default).

    Wow we really need some Hebrew users to tell us the
    ins and outs!

    > > Indian scripts don't care about position but have
    > > extremely complex ligature requirements.
    > We could improve the ligature support, but that may
    > not be the
    > best the way to go. We will need to use a 3-rd party
    > renderer for all
    > of this stuff sooner or later.

    I hope Pango can do it or that we can begin working
    with Pango in a joint effort that will be a win for
    everybody.

    > > I think these font problems are going to become a
    > more
    > > prominent problem the further we get.
    > I think you are right. That's one reason why I am so
    > keen to
    > migrate to FreeType, for that should at least make
    > things easier.

    It's an exciting time (:

    > > We need to push for Hebrew, Arabic, Thai and
    > Indian
    > > language users - or at least testers! Especially
    > the
    > > first two since they work pretty good on the
    > current
    > > AbiWord - we should really make a special effort
    > to
    > > announce AbiWord 1.0 on Hebrew and Arabic Linux
    > and/or
    > > free software sites if they exist.
    > I have been trying. There are quite a few Hebrew
    > testers involved
    > now, and it is working fairly satisfactory. Folk
    > from the
    > Arabeyes.org project expressed interest recently,
    > and hopefully we
    > will get some contributions from them.

    Is it time for us to have a Hebrew translation of the
    website?

    > There is though another problem. The Hebrew-speaking
    > folk are
    > interested in Hebrew, which means their interest
    > stops largely at
    > the level of Fribidi functionality. The Arabeyes
    > folk are interested in
    > Arabic, planning to produce shaping engine for
    > Arabic that could be
    > used alongside fribidi. For me the scope is too
    > limited. I would be
    > happy to plug in 3rd party Arabic shaping engine,
    > but ultimately I
    > want more than that. In long run, Pango (or
    > something like it) is the
    > answer, it certainly has got the vision, but even in
    > the medium run,
    > I would like to be able to do more, to support any
    > language that
    > has line-based layout and for which the shaping can
    > be done via
    > the Unicode codepoints.

    I think this really does mean Pango. Or at the worst
    a future version of Pango. I think at the very least
    we should be developing with optional Pango ASAP.
    The only alternative I can imagine is making an
    abstraction layer on top of Pango, Uniscribe, and
    ATSUI
    and this, I hear, is next to impossible.

    > > > Consequently, I want us to migrate to FreeType
    > ASAP.
    > > > This will give us a level playing field on all
    > platforms, and
    > > > rid us of huge problems on Unix and the serious
    > difficulties caused
    > > > by inconsistent behaviour of the myriad of
    > Windows.
    > >
    > > This means Xft on X too, right?
    >
    > No, FreeType is independent of any system font
    > mechanism; it
    > parses the font files and gives you the glyphs as
    > bitmaps.

    If we want to support antialiased fonts, where will
    that support come from on Linux/Unix?

    > > > As far as Pango is concerned, apart from the
    > > > portability problems, from what I have seen, its
    > API would make it very
    > > > difficult to integrate with the existing layout
    > engine. My
    > >
    > > Can you give us some concrete, technical examples?
    > > Please CC the GTK I18N list too so we can get
    > comments
    > > straight from the Pango guys.
    > No, I cannot :). But as far as I understand, Pango
    > is a fairly high
    > level formatter, it does something like our
    > fl_BlockLayout class,
    > and we would have to replace the blockLayout with it

    We can't do that. Are you sure Pango doesn't support
    multiple levels? I'm pretty sure Uniscribe does and
    I hear Pango is quite analagous to Uniscribe.

    > _to_get_most_out_of_it_. This basically means
    > throwing our entire
    > existing layout engine out and start again. It could
    > well be the best
    > thing to do right now, but I am not fully convinced.

    I don't believe Pango can do the layout stuff we need
    to do but I'm in favour of throwing out our entire
    existing layout engine if that's the way to get the
    best product.

    > > I'm under the impression that using Pango will
    > make
    > > exotic languages "just work" in places such as
    > > dialogs and widgets too. We might handle the
    > rendering
    > > nicely on screen but can we handle it in say the
    > > spellchecker window or in window title bars?
    > I am not sure that is the case; what we can do with
    > the widgets
    > depends on what the widgets can do, and that varies
    > from OS to
    > OS. But this is a real issue we will have to address
    > as well.

    True. I was thinking of the case with the new GTK/
    new Gnome. Windows 2000/XP should also "just work"
    thanks to Uniscribe but may have slightly differing
    edge cases. This would be something to iron out
    between us and Pango. I have no idea what ATSUI would
    do on OSX - hub?

    > > Again please tell us what Pango is missing for us
    > specifically.
    > I am not saying Pango is missing anything, I am
    > merely not sure
    > that the folk who advocate using Pango have strayed
    > past the
    > Pango home page. It is about time that someone
    > undertook as
    > serious feasibility study of using Pango.

    Yes I said as much some time ago. I wish I had the
    equipment to do it myself. I don't find the Pango
    home page very helpful and I have no way to get into
    the Pango code at this stage ):

    > > Surely we would use Pango only for rendering the
    > > straight "runs" of text. All formatting including
    > > tabs we would do ourselves.
    > If that is all we want to use Pango for, then we
    > have to migrate to
    > freetype first, because we will be left to do the
    > screen drawing
    > using glyph indices, and we do not want to do this

    Surely we would do this with Pango too?

    > in platform
    > specific code, because that would mean having the
    > whole shaping
    > system in platform specific code, since the indices
    > are system-
    > dependent. Also, no-one should assume that this is

    Really? This seems to be an area I need more
    knowlege of ):

    > trivial, to quote
    > from the Pango docs: "While complete access to the
    > layout
    > capabilities of Pango is provided using the detailed
    > interfaces for
    > itemization and shaping, using that functionality
    > directly involves
    > writing a fairly large amount of code."

    We shouldn't be scared of that. It sounds like a
    good thing. And doing it without Pango would involve
    a much larger amount of code IMHO.

    > > Surely if pango can give us a shape
    > > to print on the screen it can give us one to print
    > on
    > > a printer - but I don't know printers alas...
    > Pango, if used in the way you envisage, only gives
    > us a glyph
    > indices, but even if it gave us actual shapes, this
    > would be of no
    > use for generating PostScrip. In the Unix World the
    > fact we can
    > draw it on screen does not mean we can print it via
    > PostScript,
    > because we could well be using non-PostScript fonts
    > on the
    > screen. Again, I am not saying there is a problem,
    > merely that this
    > issue has to be looked into, for being able to
    > support a myriad of
    > languages on screen is not enough in itself.

    Since the new Gnome has Pango built in and used
    everywhere, how does gnomeprint cope in the new Gnome?

    > Just for the record, I am _not_ objecting to us
    > using Pango, neither
    > for low-level shaping, nor for high level layout. I
    > am objecting to
    > deciding to use Pango without thinking seriously
    > through what would be involved, what it would bring

    I agree 100% - that's why this discussion now. We
    need to thrash out all that we think we need, all that
    we think Pango can do, all that using some alternative
    would mean, etc. So far it's been very enlightening.

    > us, and *WHO WILL DO THE CODING*. The bidi
    > experience taught me that not that many
    > people will do the coding when it comes to
    > more "exotic" internationalization.

    I've always been very keen to work on it. I just
    happened to be on a world trip during most of the
    work you did. Now I just need an income or at least
    a computer and internet access and I'm itching to
    tackle it!

    > Even in its most reduced form, the migration to
    > Pango would require serious commitment from the
    > entire development team, without it we should stop
    > even talking about it right now.

    Trying to get better rendering and
    internationalization
    will require just that no matter whether we use Pango
    or not. But we should keep talking so everybody knows
    how much of a commitment it would mean. Maybe at the
    end of the day they will decide it's too ambitious
    and just do the tables etc for 1.2 and leave this till
    later. At least it they will make that decision with
    the best information available.

    > As for me, I am entirely convinced that we will have
    > to migrate to using a 3rd party layout engine sooner
    > or later, and if Pango is the best choice, let's use
    > it.

    I agree. And if something else is the best choice,
    let's use that instead.

    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 : Wed Apr 24 2002 - 11:52:13 EDT