Subject: post 1.0 layout engine
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Fri Jan 11 2002 - 04:46:57 CST
I would like to open discussion of the post 1.0 layout engine, so
that as we are fixing bugs for the 1.0 release we have something to
think about.
New/modified functionality
(1) Tables: I know Martin has given this some thought; one of the
requirenments will be a more flexible container implementation (the
current base container class is in fp_Column).
(2) Footnotes: since the endnotes are almost fully functional in the
debug code, this will be mainly a question of a container
implementation for the footnotes, and should not be too hard.
(3) Bidi: the new layout engine should be bidi-only. The latest
version of the bidi code is pretty lean and mean, and the non-bidi
users should not notice any performance difference.
(4) Glyph shaping: this goes hand in hand with bidi, and without
decent glyphshaping mechanism we cannot support Arabic, and
many other languages. We have two basic options: glyhp shaping
in the XP code, or glyph shaping in the platfrom specific code. I
would prefer the former option because (a) it will provide uniform
behaviour across all platforms; (b) will be easier to maintain. If we
take the latter path, we will have to provide glyph shaping engine for
most platforms and on win32 we will have to decide whether on
those flavours of win32 that do not do glyph shaping (which is
most) we will provide our own engine, or not support glyphshaping
at all. Pango has been usually mentioned on this list in this
context, but it is certainly not the only option, and we will need to
consider this carefully, since this will require substantial changes
to our layout classes. We also have to decide whether we will stick
with text organised in lines-only, or support columnar languages
too. Pango, I think, does both, but it would require much more
drastic rewrite of our layout code.
(4) Font rendering engine: This is closly related to glyph shaping
which can be comprehensibly provided only when using font
technology that can handle multiple glyhps for single Unicode code
point, such as OpenType. This poses real problem on Unix, since
the X server font mechanism does not provide this. I am therefore
toying with the idea of using the freeType library for our font
rendering; I think on Unix this is almost unavoidable, unless gtk 2.0
will provide OpenType support, but I think we might want to
consider using freeType in XP code.
Tomas
This archive was generated by hypermail 2b25 : Fri Jan 11 2002 - 04:47:43 CST