<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Simon,</p>
    <p>When you say "JSTF axis" does that imply that one is building a
      variable font? Or can this technique be applied to static fonts as
      well?</p>
    <p>Thanks, Bobby<br>
    </p>
    <div class="moz-cite-prefix">On 2024-02-22 07:59, Simon Cozens via
      mpeg-otspec wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:87f9b17d-447c-4b51-baae-86ba3fa654e1@simon-cozens.org">When
      Behdad, I and others did some thinking about the JSTF table last
      year (with a view to potentially making a 2.0 version which
      interacted better with variable fonts), we came to the realisation
      that everything you can do with the JSTF table, you can actually
      now do with a "JSTF" axis. So at this point it's entirely
      redundant.
      <br>
      <br>
      In fact, I think Behdad implemented JSTF-axis-based justification
      in harfbuzz. (hb_shape_justify)
      <br>
      <br>
      On 22/02/2024 14:49, nwillis--- via mpeg-otspec wrote:
      <br>
      <blockquote type="cite">The issue that always struck me about the
        JSTF table definition is that there is no accompanying
        justification engine against which you could measure whether or
        not it works, partly works, or does not work. So it's a bit
        "underanswerable." It would be like attempting to assess whether
        there is enough detail in the GSUB/GPOS spec alone that you
        could go implement HarfBuzz, Uniscribe, or any of the rest: to
        implement one you definitely have to know more about the
        behavior needed from a shaping engine than solely what's defined
        in GSUB/GPOS ... but, conversely, you have to know more about
        what the shaping engine is going to do in order to know whether
        or not the GSUB/GPOS spec is well-written.
        <br>
        <br>
        An interesting question might be to ask whether a JSTF table
        could contain all of the info needed to work for some _known_
        H&J engine — a particular TeX flavor, hz-program, or so on.
        <br>
        <br>
        I never really found a detailed account of how JSTF made it into
        the specification originally, such as describing whether it
        seemed to be written to match some particular private
        justification-engine's needs, or to match a hypothetical one
        that may have never appeared on the market.
        <br>
        <br>
        (If that info is out there, I'd certainly appreciate seeing it.)
        <br>
        <br>
        Nate
        <br>
        <br>
        ---
        <br>
        <br>
        <br>
        On 2024-02-21 16:13, John Hudson via mpeg-otspec wrote:
        <br>
        <blockquote type="cite">Simon Cozens attempted an implementation
          of JSTF table support a few
          <br>
          years ago, in an effort to find out whether it was actually
          <br>
          implementable. As I recall, he determined that much of it
          could be
          <br>
          implemented, but that there were some holes or things that
          could be
          <br>
          improved. As far as I know, there is no JSTF table support in
          any
          <br>
          shipping software, which I guess at least means we wouldn’t
          break
          <br>
          anything were we to revise the spec to produce something
          workable for
          <br>
          CSS.
          <br>
          <br>
          JH
          <br>
          <br>
          <br>
          On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec
          wrote:
          <br>
          <blockquote type="cite">The liaison statement I mentioned
            during today's call can be found here:
            <br>
<a class="moz-txt-link-freetext" href="https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf">https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf</a>
            <br>
            <br>
            One of the aspects mentioned in the CSS WG statement is
            related to using cursive elongation for text justification
            purposes, which may be desirable for cursive writing and
            could be essential e.g. for many Arabic scripts - I am
            wondering if this can already be accomplished using JSTF
            table, and whether the existing specification needs to be
            updated to support it.
            <br>
            <br>
          </blockquote>
        </blockquote>
      </blockquote>
      _______________________________________________
      <br>
      mpeg-otspec mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>
      <br>
      <a class="moz-txt-link-freetext" href="https://lists.aau.at/mailman/listinfo/mpeg-otspec">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a>
      <br>
    </blockquote>
    <div class="moz-signature">-- <br>
      Bobby de Vos<br>
      <em><a class="moz-txt-link-abbreviated" href="mailto:bobby_devos@sil.org">bobby_devos@sil.org</a></em><br>
    </div>
  </body>
</html>