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

[Bobby de Vos]

Simon,

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?

Thanks, Bobby

On 2024-02-22 07:59, Simon Cozens via mpeg-otspec wrote:
> 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.
>>>>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-- 
Bobby de Vos
/bobby_devos at sil.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240222/0ae88004/attachment-0001.htm>