Fallbacks for design sizes in the current typescripts regime

newer
Attention: Notice to registered...

older
An strange error with section and...

Hamid,Idris

22 Aug 2023 22 Aug '23

4:31 a.m.

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

Attachments:

attachment.html (text/html — 5.6 KB)

Show replies by date

Hans Hagen

22 Aug 22 Aug

7:59 a.m.

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..)

...

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

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). 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 -----------------------------------------------------------------

Hamid,Idris

3:45 p.m.

On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context , 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 ________________________________________________________________________________

Hans Hagen

4:18 p.m.

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 -----------------------------------------------------------------

Hamid,Idris

7:26 p.m.

On Aug 22, 2023, 10:21 AM -0600, Hans Hagen , 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

Wolfgang Schuster

4:27 p.m.

Hamid,Idris schrieb am 22.08.2023 um 17:45:

...

On Aug 22, 2023, 2:06 AM -0600, Hans Hagen via ntg-context , 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

Vincent Hennebert

8:53 p.m.

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 , 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

Hans Hagen

9:04 p.m.

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 , 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 -----------------------------------------------------------------

Hamid,Idris

23 Aug 23 Aug

12:56 p.m.

Hi Vincent, On Aug 22, 2023, 2:56 PM -0600, Vincent Hennebert , 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

487

Age (days ago)

488

Last active (days ago)

List overview

Download

8 comments

5 participants

participants (5)

Hamid,Idris
Hans Hagen
Hans Hagen
Vincent Hennebert
Wolfgang Schuster

Fallbacks for design sizes in the current typescripts regime

tags

participants (5)