Whilst tracking down an un-related bug, two possible
improvements in strike creation were noticed.
(1) Font.getItalicAngle() internally passed its
font transform to the code that looks up the strike,
but this was interpreted by the called code as the
device transform - which the font does not have
So the strike creation code used the font transform
as both the font transform and the device transform,
and so when a font transform is present it would
likely lead to an additional strike being created.
This doesn't cause an API-observable problem, because
the code that returns the italic angle uses user
space values, with the device transform removed.
(2) The second inefficiency is that translation components,
which do not affect the actual glyphs or their metrics,
are being used in the case where there is a font transform.
To increase the likelihood of matches, we should remove
the translation from the strike look up.