[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] RFR: 7017058: Malayalam glyph substitution is failing for Malayalam with Window
From:       Prasanta Sadhukhan <prasanta.sadhukhan () oracle ! com>
Date:       2018-09-13 6:25:01
Message-ID: 136c112c-41ae-5c62-b4d1-b482743cf4cb () oracle ! com
[Download RAW message or body]

+1

Regards
Prasanta
On 05-Sep-18 6:10 AM, Philip Race wrote:
> This fixes 3 submitted bugs
> https://bugs.openjdk.java.net/browse/JDK-7017058 : the Malayalam bug above
> And also
> https://bugs.openjdk.java.net/browse/JDK-8191130 :
> Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V
> and
> https://bugs.openjdk.java.net/browse/JDK-8195836:
> opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD 
> virama, U+200D ZWJ
>
> Webrev: http://cr.openjdk.java.net/~prr/7017058/
>
> As discussed in the evaluation of 7017058, this is because of some 
> code which
> always maps several unicode formatting characters to the invisible 
> glyph to
> ensure it is never rendered as a missing glyph box.
> But if the opentype tables in a font have glyph substitution looks ups 
> that
> depend on that font's actual mapping of those glyphs then they are broken.
> We have had several reports of this (above) and also complaints this 
> breaks
> Emoji family ligature substitution.
>
> The fix changes this to first consult the font to see if it does map 
> these codepoints.
> If it does not then we still will map to the empty glyph in which case 
> clearly the
> font can't have any lookup that depends on it.
>
> The variable origCharCode is added because several of the methods 
> mutate charCode
> and we avoid risk with this approach.
>
> The tab, NL and CR code points are still always mapped to the empty glyph
> since they are never going to be used by layout in this way and some fonts
> map TAB to a space char which is not what we want.
>
> -phil.
>
>


[Attachment #3 (text/html)]

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>+1<br>
    </p>
    Regards<br>
    Prasanta<br>
    <div class="moz-cite-prefix">On 05-Sep-18 6:10 AM, Philip Race
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:5B8F25FD.1000606@oracle.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      This fixes 3 submitted bugs<br>
      <a class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-7017058"
        moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-7017058</a>
      : the Malayalam bug above<br>
      And also<br>
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <a class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8191130"
        moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8191130</a>
      :<br>
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      Sinhala text rendering problem with C+VIRAMA+ZWJ+RA/YA+V<br>
      and<br>
      <a class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8195836:"
        moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8195836:</a><br>
      opentype:Bengali: "Khanda Ta" shaping issue with U+09A4 TA, U+09CD
      virama, U+200D ZWJ<br>
      <br>
      Webrev: <a class="moz-txt-link-freetext"
        href="http://cr.openjdk.java.net/%7Eprr/7017058/"
        moz-do-not-send="true">http://cr.openjdk.java.net/~prr/7017058/</a><br>
      <br>
      As discussed in the evaluation of 7017058, this is because of some
      code which<br>
      always maps several unicode formatting characters to the invisible
      glyph to<br>
      ensure it is never rendered as a missing glyph box.<br>
      But if the opentype tables in a font have glyph substitution looks
      ups that<br>
      depend on that font's actual mapping of those glyphs then they are
      broken.<br>
      We have had several reports of this (above) and also complaints
      this breaks<br>
      Emoji family ligature substitution.<br>
      <br>
      The fix changes this to first consult the font to see if it does
      map these codepoints.<br>
      If it does not then we still will map to the empty glyph in which
      case clearly the<br>
      font can't have any lookup that depends on it.<br>
      <br>
      The variable origCharCode is added because several of the methods
      mutate charCode<br>
      and we avoid risk with this approach.<br>
      <br>
      The tab, NL and CR code points are still always mapped to the
      empty glyph<br>
      since they are never going to be used by layout in this way and
      some fonts<br>
      map TAB to a space char which is not what we want.<br>
      <br>
      -phil.<br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>


[prev in list] [next in list] [prev in thread] [next in thread]

Configure | About | News | Add a list | Sponsored by KoreLogic