From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Sun Apr 28 2002 - 23:07:17 EDT
--- Tomas Frydrych <tomas@frydrych.uklinux.net>
wrote: >
> > 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.
Better for a viewer, much worse for a Word Processor.
I agree that we want this type of functionality but
we need *full control* over it. Whether it reside in
Pango, in AbiWord, or partly in both. The same for
smart quotes, the same for the trademark glyph, the
em-dash, etc. If we're displaying something different
than what the document specifies we have to have a way
to let the user know this. Maybe they show up when
"Show Paragraphs" is on. Maybe they show up when
"Reveal Codes" is on. Having it all done implicitly
and not querieable will not be good for us.
> 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.
But controlled by us and queriable by us.
> > 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.
Combining characters are probably included here.
> > 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.
I'm still a bit weary of bringing too much Pango space
into AbiWord space. I think it's better to keep Pango
as seperate as possible until it both proves itself
and matures.
Andrew Dunbar.
> Tomas
=====
http://linguaphile.sourceforge.net http://www.abisource.com
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
This archive was generated by hypermail 2.1.4 : Sun Apr 28 2002 - 23:09:06 EDT