JDK-8208179 : Devanagari not shown with logical fonts on Windows after removal of Lucida Sans from JDK
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2018-07-24
  • Updated: 2021-03-23
  • Resolved: 2019-04-29
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
11.0.6-oracleFixed 13 b21Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Testsuite name: Regression manual
Test name(s): java/awt/font/TextLayout/TestGASPHint.html
Product(s) tested: JDK 11.0.1 b02(64bit)
OS/architecture: Win2016 x64/Jtreg4.2 b12

Instruction:
A short piece Devanagari text should appear without any artifacts.
In particular there should be no "empty rectangles" representing the missing
glyph.

Actual behavior:
1) The Devanagari text does not shown and a string of empty rectangles shown refer to TestGASPHint.jpg.
2) The case has no such issue with JDK 10.0.2 b13 refer to TestGASPHint-2.jpg. 

Affect case:
java/awt/font/NumericShaper/ShaperTest.html

Instruction:
A line of text containing mixed numeric and other text is drawn four times.
(Depending on the font/platform, some of the other text may not be visible). There are four runs of digits, '123' at the front of the text, '456' after english text, '789' after Arabic text, and '012' after Hebrew text.
In the first line, all four runs of digits should be present as ASCII digits.
In the second line, all four runs of digits should be Arabic digits (they may not be visible if the font does not support Arabic).
In the third line,  the inital run of digits (123) and the one following the
Arabic text (789) should be Arabic, while the others should be ASCII.
In the fourth line, only the digits following the Arabic text (789) should be Arabic, and the others should be ASCII. Pass the test if this is true.

Actual behavior:
1)The Hebrew text does not shown and some empty rectangles shown refer to ShaperTest.jpg.
2) The case has no such issue with JDK 10.0.2 b13 refer to ShaperTest-2.jpg. 
Comments
Fix request (11u) Requesting fix for Oracle 11.0.6 parity. Patch applies cleanly, no regressions.
11-11-2019

Seems we also lost Thai when we lost Lucida Sans !
19-04-2019

Adding a windows devanagari font (Mangal) to the fallback list fixes it. Interestingly it is already named in the fontconfig file but used only in Hindi and Japanese(!) UTF8 locales. So in other words nearly useless except for perhaps the Hindi local case. Also interestingly a Kannada font is in the fallback list. I think if we are doing this we may want to look at why we aren't adding more Indic fonts than this for all the other reasonably common scripts for which there are Windows 7 + later UI fonts. And I think we do want to add the fonts to the fallback list,not the main list, so that they aren't included in metrics calculations. They probably won't be affect it anymore than wingdings + symbol already are but it would need to be tested. Also in the main list the fonts apply to AWT + I am not sure if we would need some code changes to support selecting encoding to use ? I think it is OK to just have these for Swing / 2D. Most of the fonts come in Plain + Bold. If we want to explicitly name the font files to use then we need to go the very verbose route of naming each font for each style of each logical font. That's 20 entries per font. But wouldn't it be nice if the implementation were smart enough to pick the Bold version of a font automatically rather than synthesising it. Well it almost is but there are catches First there can be drawbacks to that. We used to include Lucida Sans Regular and it had much better code point coverage than the Bold font and so changing to Dialog Bold would lose code points under such a behaviour. Now we no longer have this font in practice it doesn't matter to us any more. But my testing seems to show that this works only if the physical font is used before we use the logical font. If the logical font is loaded first it hides all use of the bold font - even direct ones ! So we have a bug there. The existing addition of the Tunga font for Kannada means that depending on the order of use you either get Tunga Bold when you ask for Bold *or* Tunga Regular in all cases. If we can fix that - and I suppose we have to - then we should be able to just add a simple list of the plain fonts as fallbacks and styled fonts in the same family will get used by the logical font without needing to be explicitly listed.
19-04-2019

Test build:jdk11.0.2b07(64bit) Platform:win10 x64 Jtreg tools:jtreg4.2b13 The following cases failed as the same issue: RULE "java/awt/font/NumericShaper/ShaperTest" any any RULE "java/awt/font/TextLayout/TestGASPHint" any any
14-12-2018

Since the Lucida fonts were removed, the Windows logical fonts have no support for Devanagari or Thai. We will need to update the logical fonts for Windows to make this work again, relying on Windows installed fonts. > 1)The Hebrew text does not shown and some empty rectangles shown refer to ShaperTest.jpg. The reference to Hebrew should be to Thai. The test instructions call it Hebrew but the test itself and the rendering refer to Thai.
25-07-2018

RULE "java/awt/font/NumericShaper/ShaperTest" any any RULE "java/awt/font/TextLayout/TestGASPHint" any any
24-07-2018