From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sun Apr 28 2002 - 09:55:46 EDT
> I'd kind of hoped that a sophisticated line layout system like
> Pango/Freetype could solve these issues and get kerning to work too.
> From your reading of these libraries do you if that is true?
Pango, i.e., the low-level API, will not do any layout for us at all. It
will take us from the raw Unicode text of a text run to a bitmap that
we will output on screen. It will also provide us with character and
glyphs widths, and some other useful info, but it will be up to us to
arrange the bitmaps to get the lines and blocks on screen. (The
high level API does layout into blocks, but from what Havoc said it
is not sophisticated enough for our needs -- it is aimed at simple
layout processing, such as needed in a widget set).
One of the changes here would be that the gr_CharWidth classes
and measureCharacter methods would completely go, since the
the glyph with information is provided to us by pango as we shape
the characters. Also the remapGlyph method would disappear,
because it is up to Pango to worry if a given glyph is present in the
font and what to do if it is not. Say you open a document with
some Russian text, but have no Russian fonts. If I understand
correctly, Pango might transliterate the text for you into Roman
alphabet, which is better than a document that looks like
oooooooooo.
In essence, we would be responsible for laying out runs, lines,
blocks, etc., but the truly low-level stuff to do with individual
characters, glyphs and glyph combinations, as well as specific font
techologies, would be done by Pango.
> In addition we have issues with screen dirt since clearScreen clears
> rectangular areas and some italic fonts have pixels outside their
> rectangular enclosures. You and I have fought against this with
> special case code to detect this. I can think of several ways to
> improve this.
>
> My favourite is to clear one char ahead and behind a run the redraw
> just that character.
We have to start reckoning with 0-width and negative width
characters, so we will have to look for the nearest character that
has a positive width, but otherwise that does seem to me to be the
best way.
> Thomas Flecher suggested that layout should be done with floating
> point calculations. I think I prefer that screen and print layout is
> done at the one high resolution setting. If we do it right we're
> gaurenteed to get perfect WYSIWYG for lines per page. If we could find
> a way to make it work for horizontal text layout we'd get it for the
> width too.
I was particularly wondering about the need for the two character
width arrays in the fl_BlockLayout class, and I think we do not
actually need the one in the layout units, for in layout units we
should only need the total width for each run. The one in screen
units is useful for moving the carret and drawing squigles,
selections, etc., and it is easy to fill using Pango.
About the units, Pango uses its own units, and if we use Pango,
we would be best doing our calculations in these units; there is
1024 pango units into a device unit. That should guarantee a good
precision even when working with screen at 96 dpi, and scalling to
the actual device units would be fast, using shift.
Tomas
This archive was generated by hypermail 2.1.4 : Sun Apr 28 2002 - 10:02:35 EDT