[OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode

[Steven Loomis]

This looks good to me.

-s

On 11/13/2015 2:26 PM, Philip Race wrote:
> I have managed to create a regression test that I think I can trust on 
> OS X
> Updated webrev :- http://cr.openjdk.java.net/~prr/7162125.1
>
> -phil.
>
> On 11/12/15, 9:48 PM, Philip Race wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7162125
>> Fix: http://cr.openjdk.java.net/~prr/7162125/
>>
>> The problem is that complex text layout and accompanying typographic 
>> support
>> is largely limping along on OS X and then only thanks to some canonical
>> tables that the ICU library has.
>>
>> The bug is that the internal font "peer" that passes the font tables
>> containing the necessary information for OpenType (and AAT) layout
>> does not implement the necessary functions. So there is no way to
>> get the information that the font itself contains, resulting in 
>> incorrect
>> rendering.
>>
>> The fix needs to be to add to the osx "CFont" class  the necessary
>> code to pass that information.  That is not so hard.
>>
>> But there is an additional complication that the OS X code uses
>> "fallback" or "substitution" or "cascading" fonts and so a font
>> like "Lucida Grande" might report that it supports code points
>> from  Indic scripts when it does not.  It does this by reporting
>> negative glyph codes for such cases and fixes it up in the final
>> rendering step. The problem with that is that layout needs to
>> use the font-specific tables and this subverts that. We need
>> to know for sure which code points are supported and split
>> into runs of text that the font supports. So we need to find
>> the real fonts that the CFont uses. In core text this is obtainable
>> as the cascading font list. We can get this and construct a
>> CompositeFont and make its glyph mapper check that there
>> are no *negative* glyph codes not just no zero ones.
>>
>> Now we can give layout proper runs and tables.
>> The final bit is that rendering needs to also know that if it
>> is passed a font that might implement FontSubstition that
>> it needs to expect that layout returned glyph codes that
>> are intended to be used with the Composite.
>>
>> A reliable regression test is tricky. I have looked for a simple
>> code point sequence that an installed OS X font provides that I can
>> "measure" to see that the ligature forms but have not found one.
>>
>> I have however tested using the font provided in
>> https://bugs.openjdk.java.net/browse/JDK-8139741
>> but I cannot check that in.
>>
>> -phil.
>>
>>
>>
>>
>>
>>