I used macOS 10.12.3 and I got the same cascade list for Menlo-Italic as Prasanta mentioned (with .AppleSymbolsFB substituted and .NotoSansUniversal omitted in Java code).
If it's not possible to add .NotoSansUniversal now, some Unicode ranges, apart from Arabic, will still remain not covered in OpenJDK builds (e.g. Ethiopic and Dingbats) for the Menlo-Italic case. Don't know whether that can be considered critical. Other non-hidden fonts can probably be added to cover those ranges as well, if needed. Best regards, Dmitry Batrak On Thu, Feb 16, 2017 at 8:33 AM, Prasanta Sadhukhan < prasanta.sadhuk...@oracle.com> wrote: > Hi Phil, > I was using osx10.11 but the list I enumerated in JBS is actually the > composite font I get in CCompositeGlyphMapper#convertToGlyph() which > contains those 29 slots [CCompositeGlyphMapper#convertToGlyph(unicode=value > 1575) gets the glyph code(909) from slot[4] which is CourierNewPSMT, for > italic the list was taken from convertToGlyph()] > > But, if we are considering the cascade list "listOfString", it contains > .NotoSansUniversal just before AppleColorEmoji. > > However, it does not get added to CompositeFont list because findFont2D() > returned null for it. There was another hidden font in the cascade list > ".AppleSymbolsFB" but it was changed to "AppleSymbols" and that along with > other fonts findFont2D() was able to find and could add to CompositeFont > list for convertGlyph() to use. > > Regards > Prasanta > On 2/15/2017 10:40 PM, Phil Race wrote: > > 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> 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 >>> > >>> > 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/> >>> > >>> > Regards >>> > Prasanta >>> >>> >> > > > >
