Hi,
(a.nChar1 < b.nChar1) || ((a.nChar1 == a.nChar2) && (a.nChar2 < b.nChar2))? Somehow, that expression still looks suspicious. (At least, it does not implement a lexicographical less-than relation. Not sure whether it should or not, however.)
It should not indeed. On the other hand OutputDevice::GetKerningPairs() as the only user of that buggy compare got that comment by me:
// TODO: best is to get rid of this method completely
as the method is a just a remnant of an obsolete WriterEngine/EditEngine
idea on how to layout text runs.
The method is nowadays only used by the UNO API and even if there was a user of that API (which I don't think there is) that alone should be a reason to look into what the heck it is trying to accomplish, because most probably it is doing it wrongly. So replacing the method with a dummy that always returned zero would not make a difference... Or getting rid of the related UNO API would also be a good idea if there wasn't the "UNO API semper fi" mantra.
Pair kerning is requested via the font's kerning flag and done just above the system's text run layouting. With better support for the optional OpenType features it should be moved into the layouting engines itself. There is still reason for many conflicts whether a font has a classic "kern" table or GPOS "kern" subtable or both at the same time and which layout engine handle should handle these.
Herbert