Re: Pango change, first^Wsecond baby step !

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.


   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


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 "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert

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