[NTG-context] Fallbacks for design sizes in the current typescripts regime

[NTG-context] Fallbacks for design sizes in the current typescripts regime

[Hamid,Idris]

[-- Attachment #1.1: Type: text/plain, Size: 3478 bytes --]

Dear gang,

Design sizes for typefaces -- aka "optical sizes" -- are no longer directly implemented in typescripts. From the manual Fonts out of ConTeXt by Hans Hagen, p. 109:

"at some point the decision was made to kick out these definitions and move the burden of figuring out the right size to Lua."

(Thus some large typescript collections painstakingly built over the years are now obsolete and have to be rewritten. Oh well..)

But there is an issue in the new regime:

In the old system, every typescript mapping to a font within a design-size range could have its own fallback. For example:

% Small ="small point size"
% Regular = "regular point size"
% Bigger = "bigger point size"
% Biggest = "biggest point size"

\definefontsynonym [MyRomanRegular]
    [file:MyFont-Regular.ttf] [features=<features>,fallbacks=<fallback1>]
\definefontsynonym [MyRomanSmall]
    [file:MyFont-Small.ttf] [features=<features>,fallbacks=<fallback2>]
\definefontsynonym [MyRomanBigger]
    [file:MyFont-Bigger.ttf] [features=<features>,fallbacks=<fallback3>]
\definefontsynonym [MyRomanBiggest]
    [file:MyFont-Biggest.ttf] [features=<features>,fallbacks=<fallback4>]

In the new typescripts regime we keep one font from the design-size range in the typescript file; the rest of the optical sizes go into an lfg goodies file:

\definefontsynonym [MyRomanRegular]
  \loadfontgoodies[myfonts-opticalsizes] % other three fonts go into an lfg table
    [file:MyFont-Regular.ttf] [features=<features>,fallbacks=<fallback1>]

designsizes = {
        ["MyRomanRegular"] = {
            ["7pt"]      = "file:MyFont-Small",
            ["8pt"]      = "file:MyFont-Small",
            ["9pt"]      = "file:MyFont-Regular",
            ["10pt"]    = "file:MyFont-Regular",
            ["11pt"]    = "file:MyFont-Regular",
            ["12pt"]    = "file:MyFont-Bigger",
            ["14pt"]    = "file:MyFont-Bigger",
            ["17pt"]    = "file:MyFont-Biggest",
            ["21pt"]    = "file:MyFont-Biggest",
            default  = "file:MyFont-Regular",
        },

But there is an apparent drawback to this new way of doing things: It appears that only the default font can have an explicit fallback, and there appears that there is no straightforward way to map each of the other design sizes to its own fallback.

If there is indeed no way to map each non-default design size to a fallback, then that constitutes a significant/unfortunate loss of functionality in the user interface.

If this appearance of a loss reflects the reality of the situation, would like to kindly request that the original functionality be restored to the higher-level user interface, presumably within the lfg file. So perhaps something like a keyval

    fallbacks = {
        ["MyRomanRegular"] = {
            "file:MyFont-Small"        = "fallbacks=<fallback2>",
            "file:MyFont-Regular",   = "fallbacks=<fallback1>",
            "file:MyFont-Bigger",     = "fallbacks=<fallback3>",
            "file:MyFont-Biggest",   = "fallbacks=<fallback4>",
        },

On the other hand, if access to the former functionality is still there somewhere in the user interface, would like to humbly request that someone share where it is and how to use it!

Thank you kindly for consideration of this request.

Best wishes
Idris

--
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

[-- Attachment #1.2: Type: text/html, Size: 5759 bytes --]

[-- Attachment #2: Type: text/plain, Size: 495 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hans Hagen via ntg-context]

On 8/22/2023 6:31 AM, Hamid,Idris wrote:
> Dear gang,
> 
> Design sizes for typefaces -- aka "optical sizes" -- are no longer directly implemented in typescripts. From the manual Fonts out of ConTeXt by Hans Hagen, p. 109:

You can still do it but for all these years only cm has design sizes so 
one can wonder.

> "at some point the decision was made to kick out these definitions and move the burden of figuring out the right size to Lua."

They were moved to the goodie file (there are every few design size 
setups in goodie files, minion has one, but i don't have these fonts nor 
use them.

> (Thus some large typescript collections painstakingly built over the years are now obsolete and have to be rewritten. Oh well..)

Well, i suppose one can still setup/use the typescripts but it's less 
fun. The old definefont mechanism is still there.

As a side note: we have design sizes (very few fonts) and weights (more 
and more fonts) .. weights are imo an even bigger mess, as it looks like 
some designers can't make up their mind and come with plenty weights 
independent of the fact that some look bad; variable fonts only add to 
this: the easier to use the creater tools become the easier it becomes 
to make ugly fonts (I tend to ignore fonts that show off too many 
possible choices; not much different from excessive kerning, ligatures 
and other incomplete features).

> But there is an issue in the new regime:
> 
> In the old system, every typescript mapping to a font within a design-size range could have its own fallback. For example:
> 
> % Small ="small point size"
> % Regular = "regular point size"
> % Bigger = "bigger point size"
> % Biggest = "biggest point size"
> 
> \definefontsynonym [MyRomanRegular]
>      [file:MyFont-Regular.ttf] [features=<features>,fallbacks=<fallback1>]
> \definefontsynonym [MyRomanSmall]
>      [file:MyFont-Small.ttf] [features=<features>,fallbacks=<fallback2>]
> \definefontsynonym [MyRomanBigger]
>      [file:MyFont-Bigger.ttf] [features=<features>,fallbacks=<fallback3>]
> \definefontsynonym [MyRomanBiggest]
>      [file:MyFont-Biggest.ttf] [features=<features>,fallbacks=<fallback4>]
> 
> In the new typescripts regime we keep one font from the design-size range in the typescript file; the rest of the optical sizes go into an lfg goodies file:
> 
> \definefontsynonym [MyRomanRegular]
>    \loadfontgoodies[myfonts-opticalsizes] % other three fonts go into an lfg table
>      [file:MyFont-Regular.ttf] [features=<features>,fallbacks=<fallback1>]
> 
> designsizes = {
>          ["MyRomanRegular"] = {
>              ["7pt"]      = "file:MyFont-Small",
>              ["8pt"]      = "file:MyFont-Small",
>              ["9pt"]      = "file:MyFont-Regular",
>              ["10pt"]    = "file:MyFont-Regular",
>              ["11pt"]    = "file:MyFont-Regular",
>              ["12pt"]    = "file:MyFont-Bigger",
>              ["14pt"]    = "file:MyFont-Bigger",
>              ["17pt"]    = "file:MyFont-Biggest",
>              ["21pt"]    = "file:MyFont-Biggest",
>              default  = "file:MyFont-Regular",
>          },
> 
> But there is an apparent drawback to this new way of doing things: It appears that only the default font can have an explicit fallback, and there appears that there is no straightforward way to map each of the other design sizes to its own fallback.
> 
> If there is indeed no way to map each non-default design size to a fallback, then that constitutes a significant/unfortunate loss of functionality in the user interface.
> 
> If this appearance of a loss reflects the reality of the situation, would like to kindly request that the original functionality be restored to the higher-level user interface, presumably within the lfg file. So perhaps something like a keyval
> 
>      fallbacks = {
>          ["MyRomanRegular"] = {
>              "file:MyFont-Small"        = "fallbacks=<fallback2>",
>              "file:MyFont-Regular",   = "fallbacks=<fallback1>",
>              "file:MyFont-Bigger",     = "fallbacks=<fallback3>",
>              "file:MyFont-Biggest",   = "fallbacks=<fallback4>",
>          },
> 
> On the other hand, if access to the former functionality is still there somewhere in the user interface, would like to humbly request that someone share where it is and how to use it!
> 
> Thank you kindly for consideration of this request.
I'm not going to look into this until there is a complete test case for 
this which means:

- free fonts (so that others can also test and use)
- design sizes
- fallback design sizes

Of course one can have some abstract fallback defined using the 
"MyFont-Small" namespace where the files used get remapped too as one 
goes. A bit like we do with the gyre fonts where we share definitions.

Hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hamid,Idris]

[-- Attachment #1.1: Type: text/plain, Size: 7461 bytes --]

On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context <ntg-context@ntg.nl>, wrote:
On 8/22/2023 6:31 AM, Hamid,Idris wrote:

Design sizes for typefaces -- aka "optical sizes" -- are no longer directly implemented in typescripts. From the manual Fonts out of ConTeXt by Hans Hagen, p. 109:

You can still do it but for all these years only cm has design sizes so
one can wonder.

Hm.. There are a few others, Minion perhaps being the most popular and extensive. More below:

"at some point the decision was made to kick out these definitions and move the burden of figuring out the right size to Lua."

They were moved to the goodie file (there are every few design size
setups in goodie files, minion has one, but i don't have these fonts nor
use them.

Have just completed a minion-pro-opticals typescript collection with a minion-opticalsizes.lfg.

Somehow I didn't even see yours and Mathias' minion.lfg (and associated type-imp-minion) until just now, had to figure it all out from scratch from demo.lfg and lm.lfg templates -)

(OTOH, had previously seen yours and Mikael's sophisticated minion-math.lfg)

I think that my version is/will be more complete - except for mathematics. Once some fine-tuning and additional testing is done, will donate the results to ConTeXt.

(Thus some large typescript collections painstakingly built over the years are now obsolete and have to be rewritten. Oh well..)

Well, i suppose one can still setup/use the typescripts but it's less
fun. The old definefont mechanism is still there.

Unfortunately it doesn't work anymore -  or at least not the way it used to. My mkiv minion typescript collection, for example, still compiles in lmtx, but the design sizes do not show up in the output anymore, only the default size.

As a side note: we have design sizes (very few fonts) and weights (more
and more fonts) .. weights are imo an even bigger mess, as it looks like
some designers can't make up their mind and come with plenty weights
independent of the fact that some look bad; variable fonts only add to
this: the easier to use the creater tools become the easier it becomes
to make ugly fonts (I tend to ignore fonts that show off too many
possible choices; not much different from excessive kerning, ligatures
and other incomplete features).

You make an important point, especially about the proliferation of bad fonts via more accessible tools. On a related front, there are more and more Arabic-script fonts, but hardly anything really good or useable, even from reputable foundries like Adobe. At some point, presumably, designers quit early (or the company does not care to invest the needed time and funds).

Presumably, designing good optical sizes requires more care and subtlety than designing weights.

OTOH the more professional/high-end foundries sometimes recommend certain weights for optical-sizes. For example, your neighbors at Enschede:

http://www.teff.nl/fonts/geronimo/

"While Geronimo was mainly conceived as a typeface for (small) text, it also performs well at bigger sizes most notably the lighter weights.”"

There are 12 weights total (six regular + six italic), but the lighter weights are designed to work well at larger sizes. So from 12 fonts one can create a reasonable, combined optical-size and weight space.

(Speaking of Enschede, their Lexicon typeface use an interesting/unique optical-size concept.)

One thing about the explosion of weights is that the distinction between \tf and \bf (or \it and \bi) vanishes and becomes a spectrum. In that case, presumably one would

i)  forget about \bf and \bi
ii) multiply bodyfont-typefaces and switch directly between them as needed.

Etc.

If this appearance of a loss reflects the reality of the situation, would like to kindly request that the original functionality be restored to the higher-level user interface, presumably within the lfg file. So perhaps something like a keyval

fallbacks = {
["MyRomanRegular"] = {
"file:MyFont-Small" = "fallbacks=<fallback2>",
"file:MyFont-Regular", = "fallbacks=<fallback1>",
"file:MyFont-Bigger", = "fallbacks=<fallback3>",
"file:MyFont-Biggest", = "fallbacks=<fallback4>",
},

On the other hand, if access to the former functionality is still there somewhere in the user interface, would like to humbly request that someone share where it is and how to use it!

Thank you kindly for consideration of this request.

I'm not going to look into this until there is a complete test case for
this which means:

- free fonts (so that others can also test and use)
- design sizes
- fallback design sizes

As for free fonts. MinionPro Opticals should be considered an exception to the free-fonts rubric. After all,

i)  its multiple-master design base was inspired by MetaFont/Knuth, and hence
ii) it's very popular with TeXies.

Put another way, Minion Pro should be considered an honorary TeX typeface -)

(There is also an update, Minion 3; could imagine a perfectionist user wanting to keep the option of falling back between the two for special cases.)

There are other fonts with display sizes, such as Williams Caslon (an excellent Caslon that really has that classic Oxford University Press feel), Lexicon (mentioned above), Requiem, etc.

The reason there are so few free optical-size typefaces is that they take a lot of work to get right. Indeed, really high-quality, fine-tuned free typefaces are hard to find even at single size.

So hopefully we will not punish the users of commercial fonts -)

But for free fonts with design sizes, the best example is perhaps EBGaramond, acclaimed by German typedesigner Erik Spiekermann as "one of the best Open Source fonts around."

Now EBGaramond has forked into two branches, one by the original designer Georg Duffner, the other by Octavio Pardo. Neither fork is complete, and each may have some advantage over the other. But for a serious Garamond project, an ambitious ConTeXt user may, for special purposes, wish to use some glyphs or glyph combinations from one, some from the other. For example, some glyph-set from one weight or optical size may look better than the default that comes with the main \selectbodyfont.

So in these two branches we have high quality, free, design sizes, and fallbacks. There is also a mathematics package available.

OTOH, have no need for Garamond at the moment, and need to stay focused on the main projects right now. But at least it's freely available, there are LaTeX packages already, other users can enjoy it, etc..

My own situation is more niche, but the abstract case will find creative application in numerous niche cases for other ConTeXt users as well. Every now and them a problem arises where this functionality will at least provide a convenient workaround. Such cases cannot always be foreseen..

Of course one can have some abstract fallback defined using the
"MyFont-Small" namespace where the files used get remapped too as one
goes. A bit like we do with the gyre fonts where we share definitions.

Interesting, but not sure that I fully follow. Could you kindly give some working example that illustrates what you mean? Thank you in advance.

Best wishes
Idris
--
Idris Samawi Hamid, Professor
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

________________________________________________________________________________

[-- Attachment #1.2: Type: text/html, Size: 9937 bytes --]

[-- Attachment #2: Type: text/plain, Size: 495 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hans Hagen]

On 8/22/2023 5:45 PM, Hamid,Idris wrote:

> (OTOH, had previously seen yours and Mikael's sophisticated minion-math.lfg)

It's not that complete and we only tested an old evaluation copy. Our 
policy wrt commercial fonts is now that we only look into them when we 
get (some 5) copies for context dev without any restriction of usage 
because we might want to show them in manuals or articles or 
presentations and there is no reason to spend time on them unlees we're 
paid for it.

> I think that my version is/will be more complete - except for mathematics. Once some fine-tuning and additional testing is done, will donate the results to ConTeXt.

Good.

> As for free fonts. MinionPro Opticals should be considered an exception to the free-fonts rubric. After all,
> 
> i)  its multiple-master design base was inspired by MetaFont/Knuth, and hence
> ii) it's very popular with TeXies.

I don't have that font set and am not willing to spend money in it either.

> Put another way, Minion Pro should be considered an honorary TeX typeface -)

Hm, so we should honor a font vendor for that? Do font vendors expect 
texies to spend time on something they cannot use? Also, some of these 
commercial licenses have become pretty restrictive. With respect to 
spending time on something, the same is true for some tools: supporting 
acrobat, fonts, specific file formats, features etc ... one way tickets 
... if we need it in a project i can waste the time on it, otherwise i 
rather spend the time on things we (and users) can actually use and have 
fun with.

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Wolfgang Schuster]

[-- Attachment #1.1: Type: text/plain, Size: 737 bytes --]

Hamid,Idris schrieb am 22.08.2023 um 17:45:
> On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context 
> <ntg-context@ntg.nl>, wrote:
>
>     On 8/22/2023 6:31 AM, Hamid,Idris wrote:
>
>
>         Design sizes for typefaces -- aka "optical sizes" -- are no
>         longer directly implemented in typescripts. From the manual
>         Fonts out of ConTeXt by Hans Hagen, p. 109:
>
>         You can still do it but for all these years only cm has design
>         sizes so
>         one can wonder.
>
>
> Hm.. There are a few others, Minion perhaps being the most popular and 
> extensive. More below:

We have with Antykwa Poltawskiego a second font which provides optical 
sizes and is shipped with our TeX collection.

Wolfgang


[-- Attachment #1.2: Type: text/html, Size: 1589 bytes --]

[-- Attachment #2: Type: text/plain, Size: 495 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hamid,Idris]

[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]

On Aug 22, 2023, 10:21 AM -0600, Hans Hagen <j.hagen@xs4all.nl>, wrote:
Also, some of these
commercial licenses have become pretty restrictive. With respect to
spending time on something, the same is true for some tools: supporting
acrobat, fonts, specific file formats, features etc ... one way tickets
... if we need it in a project i can waste the time on it, otherwise i
rather spend the time on things we (and users) can actually use and have
fun with.

At some point in the future, will aim to put together some typescripts using Latin Modern as base, and probably New Computer Modern (Greek, Hebrew, Coptic, etc.) and/or MLModern (slightly heavier per design size) as fallbacks.

(Also MLModern in particular is designed to match Latin Modern's encoding files etc.)

Each has its advantages and application cases for fallbacks across optical sizes, and it doesn't get more TeXie than experimenting with CM derivatives -)

(Wolfgang mentioned Antykwa Poltawskiego, and there are other possibilities as well.)

Best wishes
Idris
--
Idris Samawi Hamid, Professor
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

[-- Attachment #1.2: Type: text/html, Size: 2144 bytes --]

[-- Attachment #2: Type: text/plain, Size: 495 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Vincent Hennebert]

On Tue, 2023-08-22 at 15:45 +0000, Hamid,Idris wrote:
> On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context <ntg-
> context@ntg.nl>, wrote:
> > On 8/22/2023 6:31 AM, Hamid,Idris wrote:
> > I'm not going to look into this until there is a complete test case
> > for
> > this which means:
> > 
> > - free fonts (so that others can also test and use)
> > - design sizes
> > - fallback design sizes
> 
> The reason there are so few free optical-size typefaces is that they
> take a lot of work to get right. Indeed, really high-quality, fine-
> tuned free typefaces are hard to find even at single size. 

I don’t know about its quality, but Adobe makes the Source Serif font
available under the SIL Open Font License, with 5 optical sizes and 6
weights. I’m working on a typescript file that allows to use all those
variants, would be happy to contribute it if that’s useful.

https://github.com/adobe-fonts/source-serif


Vincent
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hans Hagen]

On 8/22/2023 10:53 PM, Vincent Hennebert wrote:
> On Tue, 2023-08-22 at 15:45 +0000, Hamid,Idris wrote:
>> On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context <ntg-
>> context@ntg.nl>, wrote:
>>> On 8/22/2023 6:31 AM, Hamid,Idris wrote:
>>> I'm not going to look into this until there is a complete test case
>>> for
>>> this which means:
>>>
>>> - free fonts (so that others can also test and use)
>>> - design sizes
>>> - fallback design sizes
>>
>> The reason there are so few free optical-size typefaces is that they
>> take a lot of work to get right. Indeed, really high-quality, fine-
>> tuned free typefaces are hard to find even at single size.
> 
> I don’t know about its quality, but Adobe makes the Source Serif font
> available under the SIL Open Font License, with 5 optical sizes and 6
> weights. I’m working on a typescript file that allows to use all those
> variants, would be happy to contribute it if that’s useful.

But aren't these basically some chosen values on variable axis? And i'm 
not sure if that works out well for all shapes is users choose their own 
values.

> https://github.com/adobe-fonts/source-serif
I suppose that you can play with the variable font and

   axis={wght=300}

(ok, using precooked variants that have the creators blessing makes 
sense of course and but then one can also argue that a variable font 
makes no sense apart from maybe showing off some technology)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________

[NTG-context] Re: Fallbacks for design sizes in the current typescripts regime

[Hamid,Idris]

[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]

Hi Vincent,
On Aug 22, 2023, 2:56 PM -0600, Vincent Hennebert <vhennebert@gmail.com>, wrote:
I don’t know about its quality, but Adobe makes the Source Serif font
available under the SIL Open Font License, with 5 optical sizes and 6
weights. I’m working on a typescript file that allows to use all those
variants, would be happy to contribute it if that’s useful.

Many thanks for sharing this useful resource. Looking forward to trying out your typescript collection for Adobe Source Serif if/when you make it available.

Best wishes
Idris
--
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

[-- Attachment #1.2: Type: text/html, Size: 1163 bytes --]

[-- Attachment #2: Type: text/plain, Size: 495 bytes --]

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : https://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : https://contextgarden.net
___________________________________________________________________________________