[MPEG-OTSPEC] CSS WG liaison to SC29 on Open Font Format (from Feb. 2020)

[Simon Cozens]

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.

In fact, I think Behdad implemented JSTF-axis-based justification in 
harfbuzz. (hb_shape_justify)

On 22/02/2024 14:49, nwillis--- via mpeg-otspec wrote:
> 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.
> 
> 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.
> 
> 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.
> 
> (If that info is out there, I'd certainly appreciate seeing it.)
> 
> Nate
> 
> ---
> 
> 
> On 2024-02-21 16:13, John Hudson via mpeg-otspec wrote:
>> Simon Cozens attempted an implementation of JSTF table support a few
>> years ago, in an effort to find out whether it was actually
>> implementable. As I recall, he determined that much of it could be
>> implemented, but that there were some holes or things that could be
>> improved. As far as I know, there is no JSTF table support in any
>> shipping software, which I guess at least means we wouldn’t break
>> anything were we to revise the spec to produce something workable for
>> CSS.
>>
>> JH
>>
>>
>> On 2024-02-20 12:39 pm, Vladimir Levantovsky via mpeg-otspec wrote:
>>> The liaison statement I mentioned during today's call can be found here:
>>> https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
>>>
>>> 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.
>>>