ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Vincent Hennebert <vhennebert@gmail.com>
To: ntg-context@ntg.nl
Subject: [NTG-context] Re: Adobe Source Typescript With Design Sizes
Date: Thu, 2 Nov 2023 21:00:17 +0100	[thread overview]
Message-ID: <a1573bec-1b45-4cc7-939e-808b9e098cf2@gmail.com> (raw)
In-Reply-To: <6b1db780-8097-46e1-a7e0-021f5f35250e@freedom.nl>

On 01/11/2023 12:36, Hans Hagen via ntg-context wrote:
> On 10/31/2023 8:18 PM, Vincent Hennebert wrote:
>> Hello there,
>>
>> I had mentioned this on a thread some (long) time ago, finally got 
>> around to finishing a first version of a typescript with the Adobe 
>> Source font family, in all its weight alternatives and design sizes 
>> (the latter being available in the Serif style only).
>>
>> Comments welcome. If it looks good I can upload it to the wiki, on the 
>> Typescripts_examples page I guess.
> 
> I have no tiem now to figure out this (somewhat excessive) amount of 
> fonts - hopefully we will not end up in a world where all fonts have 
> many weights which makes it easier for designers not to make choices and 
> delegate that to users instead. That said,
> 
> - attached a different approach

Interesting. I’ll try and extend it to include the sans and mono styles. 
I’m not sure which version will be more readable in the end. My Lua 
function to determine the font file name is a bit convoluted indeed.


> - in your variant you can put the lua in the lfg file (at the top) and 
> then add \loadfontgoodies[...] before where the functions are used

Ok. But then that means that the designsizes table will be used all the 
time, including when design sizes are disabled, right? Which would mean 
that I _must_ define the regular size as a fallback.


> I'm not sure if we can talk of design sizes here. It's more about 
> 'usage' because a display vs subhead vs ... variant is not about mixing 
> depending on scale (e.g. using display for 20 pt in a 15 pt setup versus 
> using scaled regular for 20pt and then display 20pt for e.g. a title 
> page or 50pt on posters).

I think I see your point. I think we can still talk about design sizes 
but, instead of thinking in absolute sizes, we would want to think in 
sizes relative to the font setup.

That is, instead of saying ‘Caption shall be used for sizes 6.5pt and 
below, SmText for 9.5pt and below etc.’, we would want to say ‘Caption 
shall be used for 50% of the body font size and below, SmText for 75% 
and below, etc.’

This way, design sizes would be used ‘harmoniously’ no matter the 
scaling. A poster, for instance, would usually be viewed at such a 
distance that the apparent size of small text (typeset at, say, 25pt 
when the main text is at 50pt, therefore using Caption) would match the 
apparent size of caption text in a regular document typeset at 12pt and 
read from a normal distance.

Make sense?

As a corollary: Does the design sizes mechanism used in goodies file 
allow to use relative sizes?


>> (I have Questions For the Experts further down...)
> 
> maybe a side effect of not defining a math font
> 
>> About Adobe Source
>> ==================
>>
>> The fonts are available on GitHub [1]. They are the descendants of the 
>> Source {Serif,Sans,Code} Pro fonts described in the 
>> type-imp-source.mkiv typescript available in the ConTeXt distribution. 
>> Due to major changes, Serif Pro was renamed into Serif 4 in, well, its 
>> version 4 [2] (that’s the version that introduces design sizes, a.k.a. 
>> optical sizes), and Sans Pro was renamed into Sans 3 [3].
>>
>> [1] https://github.com/adobe-fonts/
>> [2] https://github.com/adobe-fonts/source-serif/releases/tag/4.004R
>> [3] https://github.com/adobe-fonts/source-sans/issues/192
>>
>>
>> Usage
>> =====
>>
>> Short version: store the attached typescript and its helper Lua files 
>> somewhere on your file system where ConTeXt will find them 
>> ($HOME/texmf for example), then use in your document:
>>
>>      \setupbodyfont[adobesource]
>>
>> Long version: The default typescript name is adobesource (also 
>> available as adobesource-regular) and has design sizes enabled.
>>
>> Each weight is also available: adobesource-extralight, 
>> adobesource-light, etc., all the way to adobesource-black. There is 
>> also a medium weight, that selects the regular versions of Serif and 
>> Sans, but the medium version of Mono (just slightly bolder than the 
>> regular one, presumably for better on-screen rendering in terminals).
>>
>> Design sizes can be disabled by adding -nodesignsize- to the 
>> typescript name: adobesource-nodesignsize-extralight, etc.
>>
>> Finally, I thought it would be cool to over-engineer the typescript a 
>> little bit and provide direct access to the design sizes (in case one 
>> would want a narrower version for body text, or a bolder and more 
>> expanded version for titles, etc.). Here they are, again in all their 
>> weights: adobesource-caption-extralight, adobesource-smtext-light, 
>> adobesource-subhead, adobesource-display-bold, etc. The ‘regular’ 
>> design size is accessed by simply using adobesource-nodesignsize.
>>
>>
>> Questions For the Experts
>> =========================
>>
>> To avoid a gigantic typescript file with a lot of duplication, I 
>> offloaded the font filename calculation to a Lua function (see 
>> attached adobesource.lua). I initially wanted to put the Lua code 
>> inside the typescript, but then I had all sorts of weird Lua 
>> compilation errors. The very same code works fine when included in a 
>> normal document though. Could it be that typescripts are processed in 
>> some special mode that doesn’t like Lua syntax? As a workaround, I put 
>> the code in an external file and require it from inside the typescript.
>>
>> In the goodies file, I use what I believe is the largest possible font 
>> size that can be used in ConTeXt (16,383pt) to select the Display 
>> design size. Otherwise, text above that size will fall back to the 
>> default, regular design size.
>>
>> Now, since I use the goodies file only when design sizes are enabled, 
>> I thought I could make it more robust by using AdobeSource4Display as 
>> a default, that is, for any size above 16.5pt. However, if I mix 
>> design sizes enabled and disabled in a document, the disabled one 
>> seems to be using the goodies file even though it’s not mentioned in 
>> the typescript. Any idea of why? For example:
>>
>> \usetypescriptfile[adobesource]
>> \usebodyfont[adobesource]
>> \setupbodyfont[adobesource-nodesignsize]
>> \starttext
>> This text is typeset in Display when Regular should be used.
>>
>> \switchtobodyfont[adobesource]
>> This text is typeset in Regular with design sizes enabled.
>> \stoptext
>>
>>
>> What’s Next
>> ===========
>>
>> * A harmonious-looking companion math font.
>> * A harmonious-looking companion math font that uses glyphs from Adobe 
>> Serif 4 when available.
>>
>>
>> Thanks,
>> Vincent
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2023-11-02 20:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-31 19:18 [NTG-context] " Vincent Hennebert
2023-11-01 11:36 ` [NTG-context] " Hans Hagen via ntg-context
2023-11-02 20:00   ` Vincent Hennebert [this message]
2023-11-03  8:31     ` Hans Hagen

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=a1573bec-1b45-4cc7-939e-808b9e098cf2@gmail.com \
    --to=vhennebert@gmail.com \
    --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).