[OpenJDK 2D-Dev] RFR: 8203485: [freetype] text rotated on 180 degrees is too narrow
philip.race at oracle.com
Tue May 22 16:56:58 UTC 2018
+1 (approved) from me.
On 5/22/18, 9:40 AM, Andrew Brygin wrote:
> 47 static final Font fnt = new Font(Font.SERIF, Font.PLAIN, 12);
> Updated webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.01/
>> On May 22, 2018, at 7:26 PM, Philip Race<philip.race at oracle.com> wrote:
>> Fix sounds good.
>> The test has a bug
>> 47 static final Font fnt = new Font("Time New Roamn", Font.PLAIN, 1).deriveFont(12.0f);
>> "Roamn" should be "Roman”.
>> But since Linux is very unlikely to have that font, I think you should use Font.SERIF instead.
>> Actually I am unclear why you need to use deriveFont and can't
>> test this with the constructor taking int of 12.
>> On 5/22/18, 8:50 AM, Andrew Brygin wrote:
>>> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/
>>> With freetype, text rotated on 180 or 270 degrees is too narrow.
>>> Attached test case and screenshots demonstrate the problem.
>>> The problem is caused by the rounding applied to the cases of vertical
>>> and horizontal text, see freetypeScaler.c, lines 768 and 773:
>>> The rounding routine is defined as ROUND(x) ((int) (x+0.5)) (see line 48),
>>> and it gives incorrect results for negative arguments.
>>> For example, say glyph advance is 8, and we render it without rotation,
>>> and with rotation on 180 degrees. In these cases, we get ROUND(8) = 8,
>>> whereas for 180 degrees we get ROUND(-8) = -7. This rounding error
>>> leads to decrease of the width of the rendered text.
>>> For the case of integer metrics, we can expect that FT26.6 advances
>>> produced by freetype are integer, i.e. fractional part (lower 6 bits)
>>> is zero. So, we can convert them to glyph info values without floating
>>> point division, just by using integer shift. In this case, there is no
>>> need to round the floating point value to integer, and there is no need
>>> to care about sign of the argument.
More information about the 2d-dev