Re: Pango change, first^Wsecond baby step !

[Hans Breuer <hans breuer org>]

At 16:31 22.06.02 +0200, Cyrille Chepelov wrote:
> Le Sat, Jun 22, 2002, à 03:29:28PM +0200, Hans Breuer a écrit:
< [...]
> > Nevertheless with simple scripts there will be only one
> > Font within a PangoLayout.
>
> Yes, but we can't make this assumption.
Agreed.
> > >    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
Yepp.

> [...]
> 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 ;-)

> 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).
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 ;-)
 
> [...]
>
> 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)
That's where I see the built-in simple font-mapper, which I tried to
explain in a previous mail ;-)

> > 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.
Isn't something like what I proposed used to get PangoFontMetrics
with pango_font_get_metrics(pango_font, NULL);

        Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert