From: Hubert Figuiere (hub@nyorp.abisource.com)
Date: Thu Apr 25 2002 - 04:37:45 EDT
----- Forwarded message from owner-abiword-dev@abisource.com -----
To: Paul Rohr <paul@abisource.com>
Cc: abiword-dev@abisource.com
Subject: Re: random differences (was Re: selections and combining characters)
References: <3.0.5.32.20020422090436.0341acf0@mail.abisource.com>
<3.0.5.32.20020422090436.0341acf0@mail.abisource.com>
<3.0.5.32.20020423224352.03081230@mail.abisource.com>
From: Havoc Pennington <hp@redhat.com>
Date: 24 Apr 2002 22:29:13 -0400
In-Reply-To: <3.0.5.32.20020423224352.03081230@mail.abisource.com>
Message-ID: <y5welh48q9y.fsf@icon.devel.redhat.com>
Lines: 78
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Paul Rohr <paul@abisource.com> writes:
> Random differences, no. Of course. I hope we can continue to do at least
> as good a job of leveraging existing sources of usable code as we have to
> date. (I take a lot of pride in the fact that we've built so heavily on
> proven XP codebases like expat, libwv, libpng, ispell, and many
> others.)
The problem is that Pango is essentially part of the look and feel for
the GTK port. Where grapheme boundaries fall, how shaping is done,
which fonts are available, etc. etc. It's going to be a really lame
user experience if their word processor dialogs are different from the
processor itself, IMO.
I'm not much on library religion ("as many cool libraries as possible
must be used") - I wouldn't use some of the libs the AbiWord GNOME
port uses. But I think there's a real user issue here.
I also think you guys could make important enhancements to Pango.
> For example, the demands on a formatting engine (and its associated user
> experience) can change a lot across the following spectrum:
>
> - code editor with fixed-width fonts
> - widgets with small rectangular chunks of text
> - display-only formatting (such as a web browser)
> - traditional word processing
> - arbitrary page layout (more complex magazine/newspaper flows)
> - full-on typographic control (a la Wired at it's best/worst)
This is all layout stuff, and you don't want to use PangoLayout.
What you do want to use is:
- the font abstraction so you have the right set of fonts.
the API here is just like Xft pretty much, and Xft
is the standard unix font API going forward.
So the font API should work fine.
- the shapers
- the text boundary algorithm
And then there's a feature it doesn't have yet, namely printing, that
you would want to use when it exists. Maybe you could write it. ;-)
This is free software after all, and if there are just
coordination/schedule issues you can always do a temporary fork of
some kind then resync.
> I can easily imagine substantial differences across some of those
> gradations. Specifically, the more text you're handling at once, the more
> aggressive your undo globbing should arguably be.
That's all higher-level than Pango is. Pango is pretty much just
taking a Unicode string, and selecting your font glyphs.
> In short, differences certainly shouldn't be gratuitous, but I'm not totally
> convinced that one size really does fit all across so wide a spectrum. It
> very well might. I just don't know enough to tell either way.
I'm quite sure there are small details of Pango that don't quite do
what you need, but those can be fixed. We are talking free
software. Pango is loosely inspired by Uniscribe which is the
Microsoft API for all this I gather, it's meant to be quite general
and low-level.
Of course maybe you should be using Uniscribe on Windows. An
abstraction layer for Pango/Uniscribe sounds like a world of
pain... however this layer could conceivably be Pango itself, since
GTK is also supposed to fit in on Windows.
I don't know the right answer, I just find it hard to believe that
creating a whole new system for something this
fundamental/infrastructural is the right answer.
Havoc
----- End forwarded message -----
This archive was generated by hypermail 2.1.4 : Thu Apr 25 2002 - 04:37:47 EDT