[OpenJDK 2D-Dev] [9] RFR JDK-8147002:[macosx] Arabic character cannot be rendered on MacOS X

[Dmitry Batrak]

Hi,

I've tried to build OpenJDK from 'client' repository with the fix, and the
issue is still reproducible for me. Are you fixing it only for Oracle JDK
(including Lucida Sans Regular font), and not for OpenJDK? The problem is
not
that some character cannot be rendered using a particular font, it's that
rendering behaviour doesn't match what 'canDisplay' returns.

If you're interested I can share the way we've fixed this issue in our
OpenJDK-based runtime.

As you've mentioned, the problem is that
JRSFontCreateFallbackFontForCharacters returns fallback font, which is not
on
the cascaded font list, and it can be absent even in the whole list of fonts
reported by the system. On my machine, with OpenJDK, it's .GeezaProInterface
(with name starting with dot). I guess such fonts are treated by macOS as
'hidden' (just like files with names starting with dots), still they seem
to be
usable from application if requested by their name.

As JRSFontCreateFallbackFontForCharacters is a 'black box', it's hard to
make
sure cascade list we're building matches its internal logic, so we've
chosen to
build the list dynamically based on the output of
JRSFontCreateFallbackFontForCharacters itself. I can try to prepare
corresponding webrev, if you think that can be useful.

Alternative solution (and, probably, a better one strategically), would be
not
using JRSFontCreateFallbackFontForCharacters at all. The cascade list, that
is
built currently, can probably be used to perform font fallback in all cases.

Best regards,
Dmitry Batrak


> Hi All,
>
> Please review a fix for an issue which causes arabic character "alef" to
> be not rendered in osx for menlo font in italic style.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8147002
>
> The issue was actually a regression caused by the fix to JDK-7162125:
> [macosx] A font has different behaviour for ligatures depending on its
> creation mode
> in which we have added cascaded font list to find the real fonts that
> CFont uses, so that there is no need to use "negative" glyph code for
> finding the fallback fonts
> using the "subsititution"/"fallback" mechanism used by osx code.
>
> However, the above logic of using cascaded font list in CFont does not
> take into account of using JRE provided fonts like all those Lucida* ttf
> in jdk/lib/fonts/, so
> when a glyph (in this intance, arabic 'alef' character) is intended to
> be rendered in Menlo font in italic style, osx will not be able to find
> the glyph in Menlo-Italic font
> and neither in all the cascaded system fonts provided by CoreText, so it
> results in empty box.
>
> Before 7162125 fix, the fallback code in
> CoreTextSupport.m#CTS_CopyCTFallbackFontAndGlyphForJavaGlyphCode() uses
> JRSFontCreateFallbackFontForCharacters()
> was adding jre/lib/fonts to the fallback list which was causing the
> glyph to be found in "LucidaBrightRegular.ttf" font and the glyph was
> rendered.
>
> So, the proposed fix is to add jre provided font "Lucida Sans Regular"
> to the cascaded list so that we get the "alef" glyph.
> The reason for choosing "Lucida Sans Regular" over "Lucida Bright
> Regular" is, because it is the largest font file in jre and has all the
> glyph codepoints that no other font in the jre has,
> so we will not lose out on any codepoints and will help us in not
> getting missing glyph.
>
> webrev: http://cr.openjdk.java.net/~psadhukhan/8147002/webrev.00/
>
> Regards
> Prasanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170210/36757355/attachment.html>