Re: Pango change, first^Wsecond baby step !

[Hans Breuer <hans breuer org>]

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)
>
>Or: 
>	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 *
pangos_default_rect_for_a_given_size_of_font_loaded

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