Re: Pango change, first^Wsecond baby step !

At 14:24 22.06.02 +0200, Cyrille Chepelov wrote:
Le Sat, Jun 22, 2002, à 02:02:34PM +0200, Hans Breuer a écrit:


Oh, so what you call a font face is basically the aggregation of a font
family name, a style (italic/normal) and a weight (bold/normal).

Which Pango calls a PangoFontDescription (IIUC a PangoFont is what specific,
renderer-dependent subfont Pango will use to render a specific run of
glyphs). And which I call DiaFont (actually, now, DiaFont is a
PangoFontDescription plus a (cached) legacy font name).

Yupp. That's almost exacly what I expect of a DiaFont. But some
requiremets for DiaFont (used for Objects like dia_font_get_ascent 
will require to get a concrete PangoFont at a given size loaded. 
FontDescriptions can exist without any size.
The font size loaded should probably be 1.0 cm at the moment. 
Or later on the unscaled size (scale == 1.0) of the font wanted
to let the scaling error there be 0. This differs from the previous
implementation which had font size 100 as unscaled size.

PangoLayout never exposes PangoFonts directly; all aspect manipulation is
done through PFDs.

Yeah. That's because pango takes several real Fonts to make
rendering multiple languages in one layout possible. AFAIK
this is one the main parts of knowledge (and complexity)
which Pango almost completely hides from the user.

Nevertheless with simple scripts there will be only one
Font within a PangoLayout.

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

Yep. This one will be very useful for rebuilding properly the font selection
widget (that's why the Freetype #hell is still in lib/widgets.c; to be
reused (and eventually killed) as a template for the new Pango-aware font
selection widget.

I see.

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)

      pango_xft_render_layout_line_fit_in(...,PangoRectangle* max_logical_rect)
      (0 for mlr.width or height meaning, don't try to fit)

Yes, this API would make a whole lot of sense.

... and for letting Dia know a sensible default for max_logical_rect
you'll need the 'squeeze'. Your max_logical_rect is

max_logical_rect = squeeze *

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

Hmmm. Maybe I see. But I'm really not sure I do.

Me neither. It's one of the directions I'll try to tweak your
first public version. The goal simply is to keep the objects
font access as clean and simple as possible. And do the
scaling of fonts in the renderers with the most appropriate
- not yet choosen - algorithm.

But you are tweaking it now 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 ;-)

Sure. What's currently in font.c is a "first shot, let's make it barely
work" implementation. Whatever tricks and hacks afterwards to make it work
faster (there are already a couple areas where caching could help speed
things up tremendously. One obvious things is when a couple calls are done
in a row:
      foo = dia_font_get_ascent("blabla",...)
      bar = dia_font_get_descent("blabla",...)


I think we could make this look similar to

        /* Objects care for a specific font in a dia_unit.
         * Currently the font family/face and the size are
         * still splitted. If they become merged the standard
         * GtkFontSelection widget could probably be used to
         * let the user choose
        obj->font = dia_font_new ("Courier 12")

and while rendering :

        foo = dia_font_get_ascent(obj->font);
        bar = dia_font_get_descent(obj->font);

        renderer->ops->draw_string(obj->font, pos, "blahblah")

Maybe we won't have to teach the objects the concept of PangoLayout.
Maybe we will anyways; I don't know for sure (maybe we'll simply decide that
a string property has to be a DiaString, and be done with that).

Agreed. I'd prefer objects not to know about PangoLayout so the
DiaString appears to be the way to go ...

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