[Gnome-print] Re: Pango font API problems, gnome-print



On 16 Sep 2001, Owen Taylor wrote:

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

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

maybe pango_font_description_is_better_match()

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

I guess. As long as people read the docs.

/ Alex






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]