GNOME Bugzilla – Bug 116115
Make it easier to create new int/float attribute types
Last modified: 2018-05-22 12:02:49 UTC
Pango has a number of 'visible' PangoAttribute types -- language, family, style, variant, foreground, background, etc. -- that are each effectively a child type of a more generic, but 'invisible', PangoAttribute type -- string, language, color, fontdesc, etc. Each of these generic types has associated _new(), _copy(), _destroy(), and _equal() functions. While an application that uses Pango uses pango_attr_foreground_new(), etc., those functions call pango_attr_color_new(), etc. Pango supports registering new attribute types with pango_attr_type_register(). However, an application or a Pango variant that registers new attribute types doesn't have access to the _new(), _copy(), _destroy(), and _equal() functions for the generic PangoAttribute types that underlie the visible PangoAttribute types because those functions are currently 'static'. The _new(), _copy(), _destroy(), and _equal() functions for the generic PangoAttribute types should not be static and should have their prototypes in a new pango-attributes-private.h so registered PangoAttribute types can be built from the generic PangoAttribute types.
Created attachment 17834 [details] Current PangoPDF pango-attributes-private.h file: shows only functions used by PangoPDF to minimize diffs with base Pango, but should be extended to include _new(), _copy(), _destroy(), and _equal() functions for all generic PangoAttribute types.
If we make them public, we should make them public. I dont' see any reason to have them "exported but private" (There is backend-only and engine-only API in Pango, but I don't see this falling into either of those categories.) That being said, I really dislike the approach of exporting the virtual functions for people to put into their own class tables. Perhaps we could do something like: PangoAttrType pango_attr_type_register_int (const char *name); void pango_attr_int_new (PangoAttr type, int value); and keep a table of PangoAttrClass for all registered types. Feels a bit like reinventing the GObject-wheel, badly, but I certainly don't want full GOBject overhead for Pango attributes. It should be said, that I don't think having to copy pango_attr_int_copy/destroy/equal is that horrible - they are short and obvious.
I really don't care what's done provided that it's possible to create additional attribute types that behave like the built-in attribute types (without having to copy non-public functions to do so).
This should be revisited in light of bug 511130.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pango/issues/9.