JDK-8158637 : Change FontFamily.getClosestStyle() for BOLD | ITALIC case
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 8,9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-06-03
  • Updated: 2018-09-05
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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
The issue was raised in code review of JDK-8078382.

Sergey's comment http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006937.html

I am not sure but should FontFamily.getClosestStyle() be updated also?
         case Font.BOLD|Font.ITALIC:
             if (italic != null) {
                 return italic;
             } else if (bold != null) {
                 return bold;
             } else {
                 return plain;
             }
         }


And Phil's reply http://mail.openjdk.java.net/pipermail/2d-dev/2016-May/006948.html

etClosestStyle() is something of a last resort.
Historically I think it was called only when you had only a font *with* a style like bold and someone asked for plain/regular. ie for the subtractive case rather than the additive case.
So it would not apply to the case in this bug.

However OS X does not natively support synthetic styling so we may
be entering that method for the additive case on OS X.

So will not have this same bug since it just does not happen.

In which case the reamaining question is, when you only have BOLD and ITALIC and someone asks for BOLDITALIC and you can't synthesise at all, which do you give them?

I'd still lean towards ITALIC - assuming I have ITALIC, so we do not 
need to update that method. If it can be shown otherwise we can make the change.


Thus additional testing is to be perform to find out how native systems behave in this regards.