Re: Pango change, first^Wsecond baby step !

[Hans Breuer <hans breuer org>]

At 22:11 21.06.02 +0200, Cyrille Chepelov wrote:
>Le Fri, Jun 21, 2002, à 07:22:04PM +0200, Hans Breuer a écrit:
>
>> Yepp. Result attached.
>
>Wonderful ! 
>It looks like something is lying to pango-win32 the same way it does to
>pango-xft. I highly suspect the Courier(New) font to overstate its coverage
>map...
>
If you are refering to the missing glyphs represented by a small
rectangle: AFAIK this is standard behaviour if you try to force
pango with a text which can't be rendered because of missing
glpyh representations. Every PangoFont has it's own 'missing
glyph glyph'.

>Here's the result of a discussion with Lars on #dia on irc.debian.org, on
>how to rebuild dia's font API around Pango. I'll start implementing this in
>a couple hours (expect tomorrow's snapshot to break), then we'll fix the
>objects to comply with this new API (Lars had a very valid point about not
>trusting the PFD's size field, and carrying our own height attribute. We'll
>resolve inefficiencies through caching, when the need arises. It will.)
>
>Major thing is, we get rid of the hardcoded big ugly list of fonts (though
>objects may hardcode a family name -- Pango will always find sensible
>defaults, at least for Roman script).
>
IMO there should be an built-in mapping at least for the long
time commonly used fonts in the 'ugly-font list'. Not that they
should all be listed in the menu, but Pango only guarantees to
have "Sans", "Serif" and "Monospace". I'm not sure if one wants
to tweak pango.aliases to get Dia'sfonts right, especially on
win32, where by default the .alias file isn't required.
But this can probably be done later within the font machinery ...

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

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

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

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

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