From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Mon Apr 29 2002 - 14:48:43 EDT
Hi Dom,
I will try to summarize the Pango debate:
Through the debate a concensus seems to have emerged that
using Pango would be good in principle, providing we have realistic
expectations of what it will do for us and what it will demand of us,
and whether we can pull it off.
A. What we gain
------------------------
(1) we delegate the responsibility for dealing with low-level text
layout (which is complex once we start talking of substantial
globalization and advanced typographic concepts such as kerning)
to the Pango experts. This means that we will be (eventually) able
to get quality of layout which with our own resources we could not
accomplish.
(2) some of the most unpleasant platform specific, as well as XP,
code that has to do with handling Unicode text will disappear and
be replaced by largely cross-platform layer; this includes such
problematic code as the remapGlyph function, and the font
handling mess.
(3) as a consequence of (2) we would be able to move our
PostScript generation code entirely into cross-platform code.
B. What we do not gain
----------------------------------
We do not gain a high-level layout engine; the responsibility for
arranging runs of text into lines, and anything above that will remain
upon us. Further, the range of scripts and languages Pango
handles varies between the different font backends (see below),
and is currently smaller than was generally assumed.
C. What it will cost us
--------------------------------
(1) We will have to integrate Pango into the layout engine, which is
not an entirely trivial job, but I am prepared to carry that out over
the next three month, by which time I think the layout engine could
be fully functional on Unix.
(2) We would need to redesign our PostScript classes, since
Pango does not have PS output (but then neither does X ...). For
this there probably is some code out there we could reuse, but we
should not count on it. I am prepared to chip in on this, but not to
implement this single-handed (this, as has been pointed out,
amount more to adding functionality to Pango than AbiWord).
(3) We will have to make Pango available on all our platforms;
currently it is only available on Unix and win32. This mainly
amounts to porting glib, and there has been no real feedback on
this. Yet, this is absolutely critical, because no glib == no Pango.
Apart from the overall decision whether to use Pango or not (which
still remains to be made, since most of the active developers did
not voice a _clear_ opinion on that), there is a further subsequent
decision of which flavour of Pango to use. In essence there are two
options: (1) use pango on the top of the native font system, (2) use
Pango on the top of the FreeType2 backend.
The main advantage of (2) is that it would be pretty much platform
independent and we would get uniform behaviour. The arguments
put forward in favour of (1) are smaller memory footprint and
possibly better performance. Against (1) as a general approach is
the fact that Pango supports native font backends only on X and
win32, and the latter is seemingly not very adavanced.
Opinions on which way to go are divided, but my understanding
from the debate is that an initial XP implementation using the
FreeType2 backend done in a manner that would allow for future
minimal-effort replacement with a native font backends where
available would be acceptable to all, and going this way would not
pose any serious problems.
The whole Pango question is rather separate from other
internationalization issues that have been raised on the list in the
past two weeks, notably handling of selection and undo for
compozite characters; Pango will help us in a major way in drawing
these on the screen, but it will give us virtually no help in the way
we let the user to interact with these. Consequently, this will need
to separate develpment effort whether we use Pango or not, and
should be left out of the decision about use of Pango.
My personal opinion, having been initially fairly sceptical about
using Pango at this stage is that if we can manage the porting to
our platforms, we should use Pango with the next major release; I
think the benefits significantly outway the work required.
Tomas
This archive was generated by hypermail 2.1.4 : Mon Apr 29 2002 - 14:55:15 EDT