Re: Pango change, first^Wsecond baby step !

[Hans Breuer <hans breuer org>]

At 10:27 22.06.02 +0200, Cyrille Chepelov wrote:
> Le Sat, Jun 22, 2002, à 07:39:42AM +0200, Hans Breuer a écrit:
>
> [...]
>
> > 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.
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.

> [...]
> > /* 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. 
As I understood and meant the word 'font face' the hierachy is a 
FontFamily - Like Arial, Helvetica, Courier
    has different
  FontFaces - like Arial Bold, Arial Italic, etc
      which has different sized vizual representations
    DiaRendererFont

> 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()

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

> 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.
Yepp. It is meant as one way for performance improving. You don't
need to always destroy the whole layout if only it's size does 
change.

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

> > 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 ;-)

        Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert