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

Skef Iterum skef at skef.org
Fri Mar 15 16:52:45 CET 2024


Just from a conceptual level, it seems like one thing that would be easy
to do with an engine but hard to do with an axis is to control the number
of times the /same/ contracting or expanding mechanism is used on a given
line. So, to be over-simplistic, if there's a larger "fi" and a smaller 
"fi" and two
"fi" candidates on a line, making it so that only one uses the smaller and
one uses the larger.

Another thing that seems harder to with an axis is to trade off expanding
and contracting elements. So, for example, if you have a way of making
"Qu" significantly larger and a way of making "ch" slightly smaller, 
achieving
a happy medium increase in length by using both of those.

For reference for this discussion Is there some means of controlling the
number of times a given substitution is applied or trading off expanding
and contracting applications? (One could use context, of course, to
introduce some gradualness, but not always the specific degree of it one
wants.)

Skef

On 3/15/24 04:29, Simon Cozens via mpeg-otspec wrote:
> On 14/03/2024 15:02, John Hudson via mpeg-otspec wrote:
>> ‘JSTF=0 - JSTF=1000’ implies that justification always means 
>> expanding-to-fill. Conceptually, the model could handle contraction 
>> also, I think. Has this been considered in the implementation?
>
> Sure, starting the JSTF axis at zero was just an example to how 
> different things could be done along different expansion values. It 
> works mutatis mutandis the other way around: if you want a font that 
> runs JSTF=-1000 to JSTF=1000, just arrange for the glyphs to contract 
> or switch to condensed shapes at appropriate points along the negative 
> part of the axis.
>
> S
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20240315/4dbb8ea5/attachment-0001.htm>


More information about the mpeg-otspec mailing list