GNOME Bugzilla – Bug 163162
Support pango_attr_list_change() on broader set of lists
Last modified: 2018-05-22 12:08:17 UTC
Test program coming up. The final pango_attr_list_change should make character 8 bold (==700). ./testattr Original list: PangoAttrList at 21400 start=6; end=9 weight=700 start=8; end=9 weight=400 Other list: PangoAttrList at 21418 start=0; end=1 weight=700 After splice: PangoAttrList at 21400 start=6; end=10 weight=700 start=8; end=10 weight=400 After change: PangoAttrList at 21400 start=6; end=10 weight=700 start=8; end=10 weight=400
Created attachment 35574 [details] testattr.c leaks like crazy, sorry.
It looks like pango_attr_list_change assumes that no attribute is ever overridden later in the list. Thus pango_attr_list_change and pango_attr_list_splice cannot be used on lists that have ever had one of the _inserts used on them (unless something else guarantees the above property).
Well, I'm not really sure what pango_attr_list_splice() and change() *should* do on a list of that form. The basic operation of Pango works with any list created with pango_attr_list_insert() which just keeps the start indices of all the attributes in the list in non-decreasing order. But the idea of change() is that it keeps the list in a more strictly canonical form where there is only one attribute of each type at each position. If the list is not already in that form, is that a well-defined operation?
I don't see the ambiguity. An attribute list has a well-defined meaning, namely the one you get by iterating over it. If insert has been used, then the later attributes may overrule the early ones, but someone iterating will not see that. With that view, _insert and _change have the same semantics as far as the meaning of the result. On top of that, _change adds certain guarantees that it should probably spell out: 1 Any position that had no overlap (ie., no later overruling earlier) will continue to have no overlap. 2 Attributes that become adjacent because of the change will be merged. 3 Repeated changes will not cause the list to grow unboundedly. If you don't want to promise too much, 1+2 could be promised only for lists with no overruling only at all. > If the list is not already in that form, is that a well-defined operation? There might be several different possible results (like qsort has when some elements compare equal), but the basic meaning of the change operation is clear as it follows from the meaning of the list: _change needs to change the iterated meaning of the list.
A requirement for a patch implementing this being accepted would be that it doesn't make pango_attr_list_change() significantly more expensive; it also would be really nice to have test cases here to verify changes to this complex function. Marking Severity as minor because I don't know any real use cases for calling change() on lists with overlapping attributes.
*** Bug 154487 has been marked as a duplicate of this bug. ***
-- 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/21.