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