Re: Pango change, first^Wsecond baby step !

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

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

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 

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 "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert

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