If we implement #91 we'll have to deal with aggregated location strings getting much longer than before, in that case we should put the location string on a separate line (or maybe even multiple).
For this we need to:
get the text run length for both from the respective Pango layout up front, not only after rendering the texts
having the index item span more than a single line will screw up the up-front calculation that determines how many index columns are needed and whether the index will fit at all. On the other hand this calculation also does not know about aggregation of multiple lines, so it will actually calculate the right vertical space when two entries get merged, and actually leads to a too large index area estimate whenever more than two rows are aggregated. Also long label texts could lead to text wrap before already?
If we implement #91 we'll have to deal with aggregated location strings getting much longer than before, in that case we should put the location string on a separate line (or maybe even multiple).
For this we need to:
get the text run length for both from the respective Pango layout up front, not only after rendering the texts
having the index item span more than a single line will screw up the up-front calculation that determines how many index columns are needed and whether the index will fit at all. On the other hand this calculation also does not know about aggregation of multiple lines, so it will actually calculate the right vertical space when two entries get merged, and actually leads to a too large index area estimate whenever more than two rows are aggregated. Also long label texts could lead to text wrap before already?