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.
_______________________________________________
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
