Re: Pango change, first^Wsecond baby step !

[Cyrille Chepelov <cyrille chepelov org>]

Le Sat, Jun 22, 2002, à 03:29:28PM +0200, Hans Breuer a écrit:

> Yupp. That's almost exacly what I expect of a DiaFont. But some
> requiremets for DiaFont (used for Objects like dia_font_get_ascent 
> will require to get a concrete PangoFont at a given size loaded. 

s/PangoFont/Random set of PangoFonts depending on the exact glyphs needed
and the coverage maps of the available fonts for the described family/

(yuck)

> FontDescriptions can exist without any size.

FontDescriptions do embed a size.

> Nevertheless with simple scripts there will be only one
> Font within a PangoLayout.

Yes, but we can't make this assumption.


> >     pango_xft_render_layout_line_fit_in(...,PangoRectangle* max_logical_rect)
> >     (0 for mlr.width or height meaning, don't try to fit)
> >
> > Yes, this API would make a whole lot of sense.
> ... and for letting Dia know a sensible default for max_logical_rect
> you'll need the 'squeeze'. Your max_logical_rect is
>
> max_logical_rect = squeeze *
> pangos_default_rect_for_a_given_size_of_font_loaded

Or the other way around:
  max_logical_rect = rect_at_scale_1 * scaling_factor

> > Hmmm. Maybe I see. But I'm really not sure I do.
> Me neither. 

I like this <grin/>

> >           It's one of the directions I'll try to tweak your
> first public version. The goal simply is to keep the objects
> font access as clean and simple as possible. And do the
> scaling of fonts in the renderers with the most appropriate
> - not yet choosen - algorithm.

Hmmm, yes.

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...

Also, we also almost *never* use a DiaFont (except for property edition)
without passing a string argument as well. It seems (and I rejoin you) that
we'll greatly benefit from exposing an abstraction of PangoLayouts to
objects (but I would like to first complete the "raw", ie strings + fonts
API and then extend with a faster/better object).

Oh, I see we already call that DiaString. 

Basically, a DiaString would have three properties:
        * a text     (char *)
        * a font     (DiaFont)
        * a position (Point)
and, in private, obviously, a PangoLayout.

Suddenly, most of the code in objects which dealt with ascents and descents
just disappears: we can get the baseline and the bounding box very easily
out of a PangoLayout. 

The current Text object would now become merely a wrapper around DiaString
(with the extra cursor movement capabilities, using Pango's help -- think
about jumping from English to Arabic text).

(there are clear difficulties to that approach, though, especially in the
backwards compatibility departement -- that can certainly be overcome)

> I think we could make this look similar to
>
>       /* Objects care for a specific font in a dia_unit.
>        * Currently the font family/face and the size are
>        * still splitted. If they become merged the standard
>        * GtkFontSelection widget could probably be used to
>        * let the user choose
>        */
>       obj->font = dia_font_new ("Courier 12")

Yes.  The string would be a stringified PangoFontDescription -- that way we
don't even need to parse it.
 
> and while rendering :
>
>       foo = dia_font_get_ascent(obj->font);
>       bar = dia_font_get_descent(obj->font);
>
>       renderer->ops->draw_string(obj->font, pos, "blahblah")

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.

        -- Cyrille

-- 
Grumpf.