corrected: 47 static final Font fnt = new Font(Font.SERIF, Font.PLAIN, 12);
Updated webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.01/ Thanks, Andrew > On May 22, 2018, at 7:26 PM, Philip Race <philip.r...@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. > > -phil > > On 5/22/18, 8:50 AM, Andrew Brygin wrote: >> Webrev: http://cr.openjdk.java.net/~bae/8203485/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8203485 >> >> >> 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: >> >> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l768 >> >> >> http://hg.openjdk.java.net/jdk/client/file/80a5ff734fcd/src/java.desktop/share/native/libfontmanager/freetypeScaler.c#l773 >> >> >> 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. >> >> Thanks, >> Andrew >>
