Re: Pango change, first^Wsecond baby step !



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.




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