Re: Pango change, first^Wsecond baby step !

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/


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 *

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]