Re: Pango change, first^Wsecond baby step !

[Cyrille Chepelov <cyrille chepelov org>]

Le Sat, Jun 22, 2002, à 07:39:42AM +0200, Hans Breuer a écrit:

> >(behind the scenes, most diafont_* functions will actually build layouts.
> >There should be a one or two-slot cache to avoid rebuilding the same layout
> >several times in a row)
> >
> Here are some things I would like to be done different in the
> new font api.
> As we (or at least I) finally like to turn DiaFont into a
> GObject some name changes would make it more similar to
> all the other GObject based code

done.

> diafont_get_font -> dia_font_new
> diafont_get_font_static -> vanish. Exposing the Pango API
>     so much should be avoided. Instead Dia's font machinery
>     probabby should keep a reference of  

whoops, seems TCP lost a packet here.

> diafont_free -> dia_font_unref
> 
> diafont_get_font_simple_name ->
> /* the lifetime of the resturned string is guaranteed to
>  * be as long as the fonts lifetime. The string must not be 
>  * freed
>  */
> const gchar dia_font_get_legacy_name()

Makes sense. I'll apply that.

(also, the global s/diafont_/dia_font_/g )

> /* These are used from the objects */
> diafont_ascent() -> real dia_font_ascent(DiaFont,real height)

 
> My vague imagination for the Pango revamp had three players.
> DiaFont - as the font used from DiaObject code. Currently working
>           in 'cm'. There is only one such object for every
>           font face. It could be size independent and assumed to
>           scale linear. Also [in the begining] the memory management 
>           burden can be taken of the DiaObject code.
>           The object would be created on demand but could live
>           for the whole dia session.

We never ever deal with faces. We deal with PangoFontDescriptions (layout
objects don't take faces as inputs, but PFDs). The only time one has to deal
with Pango Faces is when you break a layout object down to individual glyph
runs (or almost). And I don't really think we should care down to this
level.

I will take care of the memory management issue today.

> DiaText - which manages the PangoLayout required to render fonts.
>           The layout gets changed on demand from the renderer with
>           dia_font_* functions but it's lifetime depends on DiaText.

So, instead of having one string on one hand, and one DiaFont on the other,
objects should all be transformed to store bunches of DiaText.

Makes a whole lot of sense !  Can be done in a second pass, though.

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

	-- Cyrille

-- 
Grumpf.