Re: Pango change, first^Wsecond baby step !

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)

        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",...)


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


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