looks fine.

On 22/05/2018 09:56, Philip Race wrote:
+1 (approved) from me.

-phil.

On 5/22/18, 9:40 AM, Andrew Brygin wrote:
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



--
Best regards, Sergey.

Reply via email to