> 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
