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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
