ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: "Hamid,Idris" <Idris.Hamid@ColoState.EDU>
To: "ntg-context@ntg.nl" <ntg-context@ntg.nl>
Subject: [NTG-context] Fallbacks for design sizes in the current typescripts regime
Date: Tue, 22 Aug 2023 04:31:27 +0000	[thread overview]
Message-ID: <c479ffa8-d639-4d54-b7c5-73f1e2298260@Spark> (raw)


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

             reply	other threads:[~2023-08-22  4:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22  4:31 Hamid,Idris [this message]
2023-08-22  7:59 ` [NTG-context] " Hans Hagen via ntg-context
2023-08-22 15:45   ` Hamid,Idris
2023-08-22 16:18     ` Hans Hagen
2023-08-22 19:26       ` Hamid,Idris
2023-08-22 16:27     ` Wolfgang Schuster
2023-08-22 20:53     ` Vincent Hennebert
2023-08-22 21:04       ` Hans Hagen
2023-08-23 12:56       ` Hamid,Idris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c479ffa8-d639-4d54-b7c5-73f1e2298260@Spark \
    --to=idris.hamid@colostate.edu \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).