Re: Pango font API problems, gnome-print

[Owen Taylor <otaylor redhat com>]

Alex Larsson <alexl redhat com> writes:

> On 16 Sep 2001, Owen Taylor wrote:
> 
> >    void          pango_font_description_clear_mask (PangoFontDescription       *desc,
> >    PangoFontMask               to_clear);
> 
> What does this do?

Unsets the fields specified by @to_clear. Might be better called:

 void pango_font_description_unset_fields (PangoFontDescription       *desc,
                                           PangoFontMask               to_unset);
 
> >  * Also added were a number of convenience functions for manipulating PangFontDescription:
> > 
> >    gboolean pango_font_description_better_match (const PangoFontDescription *desc,
> >                                                  const PangoFontDescription *old_match,
> >                                                  const PangoFontDescription *new_match);
> 
> What is this?

/**
 * pango_font_description_better_match:
 * @desc: a #PangoFontDecription
 * @old_match: a #PangoFontDescription, or %NULL
 * @new_match: a #PangoFontDescription
 * 
 * Determines if the style attributes of @new_match are a closer match
 * for @desc than @old_match, or if @old_match is %NULL, determines if
 * @new_match is a match at all. Approximate matching is done for
 * weight and style; other attributes must match exactly.
 * 
 * Return value: %TRUE if @new_match is a better match
 **/

It's code that had been cut-and-pasted between backends in uglier
form. A simpler alternative interface woudl be:

 gint 
 pango_font_description_find_best_match (PangoFontDescription   *desc,
                                         PangoFontDescription **to_match,
                                         gint                   n_to_match);

Or something, but that would require creating temporary arrays when they weren't
needed.

> > Questions:
> > 
> >  * pango_face_get_style_name() is a bad name, because we've already (following CSS)
> >    used style to mean normal/italic/oblique. GnomePrint seems to use 
> >    "species_name" for this purpose. A bit confusing, but perhaps less so
> >    than using "style" to mean different things.
> > 
> >    "get_name" and "get_face_name" don't strike me as good alternative names
> >    since they imply a name that specifies the face within all available faces, not 
> >    the face within the family.
> 
> subfamily_type? :/

Hmmm. No. :-)

> >     - For the internals of Pango (pango_itemize(), etc), the same effect could
> >       be solved with an internal API 
> > 
> >     - The pursuit of efficiency to the following ugliness the pango_attr_iterator_get_font() 
> >       docs:
> > 
> >      * @desc: a #PangoFontDescription to fill in with the current values.
> >      *        The family name in this structure will be set using
> >      *        pango_font_description_set_family_static using values from
> >      *        an attribute in the #PangoAttrList associated with the iterator,
> >      *        so if you plan to keep it around, you must call:
> >      *        pango_font_description_set_family (desc, pango_font_description_get_family (desc)).
> 
> Can you not add pango_attr_iterator_get_font_static() ?

That would strike me as:

 pango_complicated_operation
 pango_complicated_operation_with_weird_but_faster_memory_management_operation()

That is ... set_family_name(), _copy(), and merge() are all about setting fields
in a PangoFontDescription, so the idea of having variants with different memory
management for the fields is fairly easy to grasp. pango_attr_iterator_get_font()
has several things going on, and the idea of having variants of it for different
memory management strategies for fields strikes me as being a little too
baroque.

I don't think adding a _static variant would be *bad*, but I don't think it would
actually simplify things for people using get_font().

Regards,
                                        Owen