[OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode
jennifer.godinez at oracle.com
Mon Nov 16 23:53:20 UTC 2015
Looks good. Approved.
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
> 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
>> 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
>> 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
>> but I cannot check that in.
More information about the 2d-dev