Since the common case of initializing hb_feature_t is something like { HB_TAG('k','e','r','n'), !!kerningEnabled, 0, -1 } , where "0, -1" means "the entire segment" and start/end fields are of unsigned int type, it probably worth of introducing some special constant/enum to avoid compilation warnings and to improve the code readability a bit; i.e. EntireSegment = (unsigned int)-1 // ### some better name needed note: idea pointed out by Konstantin Ritt, kudos to him.
http://lists.freedesktop.org/archives/harfbuzz/2013-December/003931.html
Luis, you are awesome!
I'm still thinking about the best name for this, in particular in light of a few API changes I'm going to propose to the list soon.
Cool! Looking forward to those. Let me know if I can help, and assign this bug to me once you have decided the best name.
Dumping what I have in mind, to replace hb_feature_t. #define HB_CLUSTER_INVALID ((uint32_t) -1) #define HB_RANGE_GLOBAL_START ((unsigned int) 0) #define HB_RANGE_GLOBAL_END ((unsigned int) -1) #define HB_RANGE_GLOBAL {HB_RANGE_GLOBAL_START, HB_RANGE_GLOBAL_END} typedef struct hb_range_t { unsigned int start; unsigned int end; } hb_range_t; typedef struct hb_feature_setting_t { hb_tag_t tag; uint32_t value; } hb_feature_setting_t; Not sure what to do with hb_feature_t. We can either deprecate it and introduce: typedef struct hb_feature_setting_range_t { hb_feature_setting_t setting; hb_range_t range; } hb_feature_range_t; Or deprecate it and make new hb_shape() variation take separate arrays for settings and range. Or ???
Moved to https://github.com/harfbuzz/harfbuzz/issues/1141
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.