JDK-8218854 : FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 7,8,11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-02-12
  • Updated: 2020-02-26
  • Resolved: 2019-03-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 Other
11.0.4Fixed 13 b14Fixed openjdk7uFixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
On fonts where algorithmic bold is applied, FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth.

This bug was noticed in JDK-11 with Z003-MediumItalic.otf font (1px, italic + bold style, default rendering mode). Char point 37 width was greater than the max advance (2px vs. 1px). Libfreetype 2.6 font rendering library in Linux was used.

A test case that reproduces the above scenario is attached to this ticket. Note: test case works before changset for JDK-8214002 was introduced into main line. This changeset prevents the test case from triggering the bug but the root cause was not fixed.

Test case failure message is:

Testing java.awt.Font[family=Z003,name=Z003-MediumItalic,style=bolditalic,size=1] in FT_LOAD_TARGET_MONO
getMaxAdvance: 1
Exception in thread "main" java.lang.Exception: FAILED: getMaxAdvance is not max for font: java.awt.Font[family=Z003,name=Z003-MediumItalic,style=bolditalic,size=1]getMaxAdvance(): 1getWidths()[37]: 2
	at MaxAdvanceIsMax.main(MaxAdvanceIsMax.java:135)

Expected value is:

"TEST PASS - OK"

The root cause of this bug is well understood. FontMetrics.getMaxAdvance value is based on a font file attribute and the scale. Assuming the font file attribute is correct, the effects of applying algorithmic bold are not taken into account at all. On the other hand, FontMetrics.charWidth renders the glyph (a bitmap previous to JDK-8214002, or an outline after JDK-8214002) to obtain the char width. If algorithmic bold were required, it's applied calling FT_GlyphSlot_Embolden and its effects are considered. For a given scale and rendering modes, effects may become visible on the width value. FontMetrics.getMaxAdvance should have considered the effects of applying algorithmic bold to return a more accurate value.

We can compare this issue with algorithmic obliqueness. The difference is that FontMetrics.getMaxAdvance takes into account the effect of applying obliqueness and adds a value based on Libfreetype internals.

One possible way to fix this issue would be to follow the same strategy and add a value, taken from Libfreetype internals, in case of algorithmic bold. The Libfreetype function related to algorithmic bold is FT_GlyphSlot_Embolden.

As part of this ticket, we propose to update algorithmic obliqueness value to align with the current libfreetype version (2.9.1).
Comments
Fix Request jdk8u release is affected by this bug, the same way jdk11u was. Patch is small and applies almost cleanly (just minor path changes to jdk11u patch).
12-07-2019

Fix request See https://bugs.openjdk.java.net/browse/JDK-8218854?focusedCommentId=14251455&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251455 This patch is now in JDK main line. We will also backport 8221304 to disable the test for macOS and Solaris.
17-04-2019

jdk11u-fix request and approval labels removed per withdrawn at https://bugs.openjdk.java.net/browse/JDK-8218854?focusedCommentId=14251696&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14251696
17-04-2019

We've decided to put the jdk11u backport on-hold until an issue related to the proposed fix, shown in macOS and Solaris, is fixed.
20-03-2019

11u fix approval withdrawn.
16-03-2019

Fix Request I'd like to have this bug fix backported to jdk11u. The reason is that this release is currently affected by this bug. Please note that only some fonts are able trigger it. The patch applies cleanly and the risk is low. There is a test case included to ensure that no regressions occur. Here it's the patch: http://cr.openjdk.java.net/~mbalao/webrevs/8218854/8218854.webrev.jdk11u.00/
14-03-2019