Hi,
I don't know what versions of MacOS X either of you (Dmitry+Prasanta)
used but I am going to guess they are different
(can you both report these, for the record).
In https://bugs.openjdk.java.net/browse/JDK-8147002, Prasanta enumerates
the cascade list for the Italic case and I don't see .NotoSansUniversal
anywhere on that list.
So although if enumerated it likely still won't work (since it is not
enumerated by the other APIs),
there does not appear to be any font in the cascade list reported by
Prasanta that "would not work",
so the fix still seems fine to me as it is plugging a gap.
A fix for using "hidden" fonts in the cascade list seems like a JDK 10
candidate unless there
is some critical case we are still missing.
-phil.
On 02/13/2017 01:56 AM, Dmitry Batrak wrote:
> Yes, we are aware this fixed it only for Oracle JDK.
> The bit I missed is that GeezaProInterface was then used on OpenJDK by JRS.
> So we could add that as well.
> If you have any other fonts you think should be added to the tail of that
list we
> can add them too.
I ran JRSFontCreateFallbackFontForCharacters against all Unicode code
points with Menlo-Italic as base font,
and got 63 possible fallback fonts - vs 29 present in cascade list,
currently used by JDK 9 (given in JDK-8147002).
So the mismatch is quite large. But the interesting thing is that
cascade list returned by
CTFontCopyDefaultCascadeListForLanguages still covers that whole
Unicode range. The problem is that JDK
doesn't use that list fully. In particular, Arabic alef letter U+0627
can be displayed using the font
.NotoSansUniversal from that list. This font doesn't get into
composite font, as it's not found among the fonts
known to Java. So a better fix (and still quite small) will probably
be using those 'hidden' fonts as part of
cascade composites - by creating a new, 'local' CFont instance if
lookup in the known font list fails
(this, btw, seems to work fine for us). If even this is considered
risky for JDK 9, then probably adding
.NotoSansUniversal with or instead of .GeezaProInterface as a
hardcoded component makes sense.
Best regards,
Dmitry Batrak
On Fri, Feb 10, 2017 at 8:19 PM, Phil Race <philip.r...@oracle.com
<mailto:philip.r...@oracle.com>> wrote:
I think that so long as we are using JRS* in some places and
CoreText's cascading list
in others there is the likelihood of some inconsistency where JRS
introduces some magic
that we don't know about
So canDisplay() needs to be fixed to be consistent and perhaps we
also need to see
if we are always getting the glyphs from the same fonts for the
cases where there
is no missing glyph.
I do agree that getting away from JRS* support is the way to go so
we are in control.
However not at this time in JDK 9.
Yes "." fonts are not enumerated by OS X but if you can find them
they work.
This is how the UI fonts are handled.
Yes, we are aware this fixed it only for Oracle JDK.
The bit I missed is that GeezaProInterface was then used on
OpenJDK by JRS.
So we could add that as well.
If you have any other fonts you think should be added to the tail
of that list we
can add them too.
-phil.
On 02/10/2017 07:59 AM, Dmitry Batrak wrote:
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
<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/
<http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/>
<http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/
<http://cr.openjdk.java.net/%7Epsadhukhan/8147002/webrev.00/>>
>
> Regards
> Prasanta
