Even though the docs try to dismiss any guarantees as to the behavior of the operator, they do mention it's there to make QFont usable as keys in QMap. QMap, being a wrapper around std::map, requires the key type to be sorted using a strict weak ordering. The current QFont::operator<() is not a strict weak ordering. In particular, because of the way the `features` QHash is compared (lexicographically, as far as I can make out), and due to the nature of QHash as an unordered container, it can easily happen that two QFont objects compare equal, but one is _also_ less than the other, according to this operator. To see this, consider that two QHash objects are equal if their linearizations are permutations of each other, but that doesn't mean that these linearizations need to be lexicograpically equal: {{1, 2}, {2, 4}} is a permutation of {{2, 4}, {1, 2}}, but the former is lexicographically strictly less the latter. The minimal fix is to use a QMap instead of a QHash. QMaps are ordered, so their linearizations are stable. A more comprehensive fix would kick out the QMap for either the std::map original, which, unlike QMap, already provides operator< that we could just use, or QFlatMap, depending on how many elements we expect in this container. Due to the leakage of of these types into other parts of the code, including public API in QTextFormat, that would be a larger undertaking, so is left for another day. I am not, yet, fully convinced that the preceding size() check does not also break strict-weak-ordering'ness, but at least it will not cause _equal_ fonts to be reported as strictly less, too. A port to lexicographical comparison would remove the last doubt, but is left for a follow-up patch. Amends 6160ea45b689e9d26795a18f155053ac4dc4dd6b. Task-number: QTBUG-142246 Pick-to: 6.10 6.8 Change-Id: I3db7b370592e100efaf5148e4c0e91d1d1925830 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io> Reviewed-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>