From: Hans Hagen via ntg-context <ntg-context@ntg.nl>
To: "J. P. Ascher" <jpa4q@virginia.edu>
Cc: Hans Hagen <j.hagen@xs4all.nl>,
mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Fallback fails for Linux Libertine O to Junicode over private area, debugging?
Date: Sat, 8 Jan 2022 11:42:20 +0100 [thread overview]
Message-ID: <f876199f-b245-b6cf-a67e-b640a010359a@xs4all.nl> (raw)
In-Reply-To: <m04k6f9q02.fsf@virginia.edu>
On 1/7/2022 10:39 PM, J. P. Ascher wrote:
>> in that case you can best use a rather bare font i.e. no features at
>> all apart from kerning and use dynamic features grouped
>>
>> in lmtx there are other tricks too
>>
>> \noleftligaturing
>> \norightligaturing
>> \noligaturing
>>
>> and other conbtrols like
>>
>> \noleftkerning
>> etc
>
> This is very useful. I'm thinking of writing an environment that
> switches: I like keeping the ease of typing normal characters, rather
> than getting glyphs directly, because it's easier to proof on screen in
> the editor.
>
>>> writing about reproduced in my work and thus now can in the historical
>>> item itself.
>>
>> one aspect is how ligatures are made: some fonts have single shapes,
>> others use replacements and kerning of (then) multiple shapes
>
> I think you wrote about this somewhere else and it got me interested in
> physical type from my period: it looks like some printers did some of
> the same things, sometimes! You might have a box of pre-composed
> ligatures, or not; you might take a knife to some letters to tweak them
> for specific uses, or not; you might even shave wrong-sized letters to
> fit them in where they don't belong. Those shaved down letters could
> end up back with their siblings, now shifting around during printing, or
> they could be tossed.
>
> The pre-composed ligatures might most often be made on matrices struck
> with the same punches as for the non-ligatured glyphs, but typefounders
> might re-strike matries now and then, so you might end up with slightly
> different pre-composed ligatures in different, or even the same, fount
> of type. It's nuts!
>
> Fred Smeijers writes about this a little bit in *Counterpunch*, but
> I had already started thinking about it because of ConTeXt.
>
> I wouldn't have known to look if it weren't for the typographical
> education you and your colleagues pass around; so, thank you again!
One problem with writing about things related to fonts is that when a
font changes rendering changes 9this is a pain for manuals or articles
that then no longer show examplex right)
for that reason one needs to
- save a font, best rename it
- define fonts by filename
- make sure that font specific manipulations are also saved
Fonts more and more have become like programs. In the past a font never
changed (even expensive fonts had no update policy like programs do) but
with open type fonts became way less stable especially free ones
(vendors still freeze and then just sell them). Add to that forking,
abandoning etc. With complex features being used, and features not
always being applied consistently (bascially we have 1-1, 1-many,
many-1, many-many mapping plus contextual lookups) we can expect bugs
and they get fixed or not. It also depends on views of designer,
programs being used to make them, programs used to test them, all of
which can change over time, so in a way fonts have become less stable (a
bit like hyphenation patterns as more fluid resource). At some point we
can expect bug(let)s or imperfections to stay and adapt to that (as we
do with math now). (This is not new: for a long time tex users had to
deal with computer modern fonts with basically only proper kerning for
english.)
Add to that evolving technologies (color fonts, image based ones e.g.
emoji, variable fonts) that show up, then need fonts, where often the
first ones are not okay, so bug show up, features changes, specs become
better (or worse), bugs become features when programs compensate for
issues, often a side effect of release before maturing (the haste of/on
the web) but all that can settle after a decade (because in the tex
world we talk decades anyway). In context so far we managed to keep up
with e.g. color fonts, variables fonts pretty early (we were one of the
first to actually typeset with variable fonts) but that of course also
comes a price of later adaptation (when fonts show up, specs become
clear). Here definitely a longer time scale matters so using such fonts
in a project is more tricky for various reasons.
The best would be if we had a repository for context where we put fonts
(clean file names, maybe with normalized version/date in file name) that
we can then trust to stay the same. In that case a typescript and lua
extensions can check for versions reliable.
(We might do that for math to start 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 / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
next prev parent reply other threads:[~2022-01-08 10:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 15:18 J. P. Ascher via ntg-context
2022-01-07 16:52 ` Youssef Cherem via ntg-context
2022-01-07 16:59 ` J. P. Ascher via ntg-context
2022-01-07 18:33 ` Hans Hagen via ntg-context
2022-01-07 17:10 ` Hans Hagen via ntg-context
2022-01-07 18:55 ` J. P. Ascher via ntg-context
2022-01-07 19:19 ` Hans Hagen via ntg-context
2022-01-07 21:39 ` J. P. Ascher via ntg-context
2022-01-07 22:01 ` Why mtxrun fails ? Jean-Pierre Delange via ntg-context
2022-01-07 22:40 ` Otared Kavian via ntg-context
2022-01-07 23:00 ` Youssef Cherem via ntg-context
2022-01-08 0:42 ` Jean-Pierre Delange via ntg-context
2022-01-08 0:48 ` Jean-Pierre Delange via ntg-context
2022-01-08 0:45 ` Jean-Pierre Delange via ntg-context
2022-01-08 8:05 ` juh via ntg-context
2022-01-08 10:42 ` Hans Hagen via ntg-context [this message]
2022-01-07 18:23 ` Fallback fails for Linux Libertine O to Junicode over private area, debugging? Hans Hagen via ntg-context
2022-01-07 19:11 ` J. P. Ascher via ntg-context
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=f876199f-b245-b6cf-a67e-b640a010359a@xs4all.nl \
--to=ntg-context@ntg.nl \
--cc=j.hagen@xs4all.nl \
--cc=jpa4q@virginia.edu \
/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).