Re: Pango change, first^Wsecond baby step !

[Cyrille Chepelov <cyrille chepelov org>]

Le Sat, Jun 22, 2002, à 02:02:34PM +0200, Hans Breuer a écrit:

> Yepp. The old problem of thinking faster than being able to type :-)
> It maybe that I was thinking of the FontFace idea here, which creates
> the font face for a longer life time and can (or even must take
> care of the font_names lifetime anyway. But but see below.

Oh, so what you call a font face is basically the aggregation of a font
family name, a style (italic/normal) and a weight (bold/normal).

Which Pango calls a PangoFontDescription (IIUC a PangoFont is what specific,
renderer-dependent subfont Pango will use to render a specific run of
glyphs). And which I call DiaFont (actually, now, DiaFont is a
PangoFontDescription plus a (cached) legacy font name).

PangoLayout never exposes PangoFonts directly; all aspect manipulation is
done through PFDs.


> > We deal with PangoFontDescriptions (layout objects don't 
> > take faces as inputs, but PFDs). 
> IIRC the 'faces' is a point where the naming in the Pango API
> isn't that good. See pango_font_family_list_faces()

Yep. This one will be very useful for rebuilding properly the font selection
widget (that's why the Freetype #hell is still in lib/widgets.c; to be
reused (and eventually killed) as a template for the new Pango-aware font
selection widget.
 
> I almost agree. It would be nice if finally there is something in
> pango like pango_win32_render_layout_line_with_squeeze(...)
>
>
> squeeze as a parameter in percent how much tighter or broader
> the layout with should be compared to the original. (Trade
> linear scale for kerning, etc)

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


> > > DiaRendererFont - which is used to adapt the real font size when
> > >           zooming/displaying. It may be useful to cache it in
> > >           a private list of DiaFont.
> >
> > I don't think we need to expose this. Besides, the real font size depends on
> > what exactly is displayed (MMMMMM doesn't scale the same way than .......
> > with Arial, for instance). We should definitely have some caching mechanism
> > in place, however
> You meant the real string width or layout width does depend on the actual
> text. My word 'real font size' should have probably the changing font 
> size. Uhm. what I meant was what's called font_scaled in the current
> font.h ... 
>
>           expected size at current scale, calculated
> squeeze = -------------------------------------------
>              measured size with scaled font height

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

> > > BTW: just looked in your new patch and noticed some code for the
> > > fonts-dont-scale-linear problem. My own small experiments have
> > > proven the fact, that there is no way against the aspect ratio
> > > cahnging slightly. Instead of tweaking it by setting a different
> > > height, font stretch etc. one solution could be to place every
> > > single character on it's own and pemanently compensate the 
> > > stretching error. I've already some code to do this with the 
> > > plain win32 api ...
> >
> > Does this code work with devanagri script ? I don't even want to try...
> > anyway, this can be tweaked later.
> But you are tweaking it know in diafont_scaled_build_layout() ?
> Ok I'm highly interested in how good this could work, too.
> But I don't wan't to buy a new CPU for that ;-)

Sure. What's currently in font.c is a "first shot, let's make it barely
work" implementation. Whatever tricks and hacks afterwards to make it work
faster (there are already a couple areas where caching could help speed
things up tremendously. One obvious things is when a couple calls are done
in a row:
        foo = dia_font_get_ascent("blabla",...)
        bar = dia_font_get_descent("blabla",...)

        renderer->ops->draw_font("blabla",...)

Maybe we won't have to teach the objects the concept of PangoLayout.
Maybe we will anyways; I don't know for sure (maybe we'll simply decide that
a string property has to be a DiaString, and be done with that).

        -- Cyrille

-- 
Grumpf.