Re: Pango change, first^Wsecond baby step !
- From: Cyrille Chepelov <cyrille chepelov org>
- To: dia-list gnome org
- Subject: Re: Pango change, first^Wsecond baby step !
- Date: Sat, 22 Jun 2002 10:27:16 +0200
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]