Re: Pango change, first^Wsecond baby step !

[Cyrille Chepelov <cyrille chepelov org>]

Le Sat, Jun 22, 2002, à 04:40:53PM +0200, Hans Breuer a écrit:

> >One thing which becomes more and more self-evident as I convert objects, is
> >that we almost *never* ever use a DiaFont without passing a size argument as
> >well. This pleads for putting the (nominal) size >inside< DiaFont...
> >
> This sounds like you already have something to play with.
> Are you willing to share work before you have converted any objects
> to DiaFont? IMO it's perectly ok to have some broken stuff in cvs
> if there is a clear commitment to fix it as soon as possible ;-)

I do have something, which doesn't completely compile. I keep incremental
patches over CVS at http://www.chepelov.org/cyrille/dia ; I planned to
commit in the next couple of hours; but I will commit now instead (lib,
objects and plug-ins seem to compile. app/ is still completely untouched)

What I wanted to do was to carry on the bulk of the new DiaFont change, and
commit with something more than two hands can tinker with (there will be
lots of run-time breakage to fix about everywhere). 

The next potential transformations:
	* DiaFont also includes height 
	* DiaString is a chunk of text with visual attributes and a position
on a diagram 

need to be more discussed before they can take place; besides, the first one
is basically a mechanical change over the whole tree (can happen while
others do modifications), and the second one can happen gradually, on an
object-by-object basis (and should be well planned, to avoid loosing old
diagrams).


> Again, do you first plan to change all the objects before letting 
> someone else take a look?  To me it appears to be much simpler
> to let the new API evolve at a restricted set of objects (say
> Standard, UML, ...) and plug-ins (I'd take wmf, python, ...)
> and get better ideas at that instead of converting all and
> then restructuring all again ;-)

I can't make the GdkFont -> Pango transition (first stage) happen in a
gradual way (well, maybe I could have, but it would have meant more work).
However, the next changes should happen gradually, in short
change-compile-test-commit cycles.
  

> >No. The ascent and descent depend on the scripts used; there is no such
> >thing as a function converting a PangoFontDescription to a pair of
> >(ascent;descent). That's simply impossible until you tell Pango which
> >scripts you're actually going to display.
> >
> Isn't something like what I proposed used to get PangoFontMetrics
> with pango_font_get_metrics(pango_font, NULL);

but to use this, you have to break down to the individual font 
(pango_font_foo()), which means you know which part of the Unicode map 
you're going to restrict yourself to (or you know which specific glyphs 
you're going to render).

>From what I understand of Pango:

PangoFonts are associated to homogeneous (coverage map-wise) runs of Glyphs
 (PangoGlyphString, IIRC)
PangoFontDescriptions are associated with PangoLayouts (and PangoLayoutLines).
	
I don't believe we really want to be so intimate with Pango (except in a
couple renderers, probably, but probably not renderer_gdk) that we want to
ever deal with PangoFonts.

Can you point me to a quick, comprehensive and well-written primer on
GObject ?

	-- Cyrille

-- 
Grumpf.