Text width calculations are naive

In QString we have leftJustified(), rightJustified() and arg() taking a fillChar and width; some field specifiers to its sprintf() do similar padding. In QTBUG-122834 we add some parameters to QLocale methods with kindred effect, that aim to behave compatibly with existing QLocaleData methods (e.g. doubleToString() and integer formatting).

In QString the methods simply count indexing within the QString, so width is measured in UTF-16 length, not in number of Unicode characters encoded or in any way that reflects the actual width that the text would take up if displayed. We can perhaps justify or at least (given that it's long-established) excuse this by the argument that QString is unashamedly a UTF-16 container and its meaning of "width" is measured in two-byte units. Furthermore, its number-formatting is (since 6.0) always in the C locale, so the digit-width issue discussed below does not arise. None the less, in light of the following, we may want to review that and consider changing the behaviour, possibly via an opt-in.

In QLocale, however, we know about non-BMP characters and could even take into account things like whether the character is zero-width, double-width or otherwise not simple. In particular, the existing number formatting methods (and now the QTBUG-122834 additions) take account of surrogate pairs when deciding on widths of fields. Thus the notion of "width" in use by QLocale at present "number of Unicode characters".

However, none of these take into account the distinction between zero-width, single-width and double-width characters, that qunicodetables* can tell us about. The case can be made that this would be worth doing in QLocale, although I doubt we can justify such a behaviour change in QString. In QLocale it would imply changing the behaviour of existing localized formatting of numbers, along with that of QTBUG-122834's additions.

Note that even taking into account the Unicode nominal width of characters falls short of what affects rendering, where Unicode characters may be grouped into glyphs, whose widths may vary considerably (for the simplest example, standard typesetting units em and ex are distinct widths based on the sizes of single letters).