From: "Hamid,Idris" <Idris.Hamid@ColoState.EDU>
To: "ntg-context@ntg.nl" <ntg-context@ntg.nl>
Subject: [NTG-context] Inconsistent behavior: \addfontfeature and CLD local function
Date: Sun, 20 Aug 2023 15:33:11 +0000 [thread overview]
Message-ID: <a20b95b3-7d75-49d2-bcb3-8e9f45fd21b0@Spark> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3388 bytes --]
Dear gang,
For \addfeature and the like, a virtual font feature defined in terms of a CLD local function behaves differently from other font features. MWE:
==============
\startluacode
local function squeeze(tfmdata)
for k, v in next, tfmdata.characters do
v.width = 1.75 * (v.height or 0)
v.depth = 1.75 * (v.depth or 0)
end
end
local specification = {
name = "sqtfm",
description = "test",
manipulators = {
base = squeeze,
node = squeeze,
}
}
fonts.handlers.otf.features.register(specification)
\stopluacode
\definefontfeature[forceno]
[mode=node,
script=latn]
\definefontfeature[forceyes]
[mode=node,
script=latn,
smcp=force,
sqtfm=force]
% smcp=yes,
% sqtfm=yes]
\showglyphs
\startTEXpage[offset=1em]
\definedfont[texgyretermes-regular*forceyes]
% \definedfont[texgyretermes-regular*forceno]
% \addfeature{forceyes}
abcdefg
\stopTEXpage
==============
You may toggle these lines:
\definedfont[texgyretermes-regular*forceyes]
% \definedfont[texgyretermes-regular*forceno]
% \addfeature{forceyes}
With
\definedfont[texgyretermes-regular*forceyes]
active we get the expected result: small caps plus some negative squeeze (= spread in this case).
With
\definedfont[texgyretermes-regular*forceno]
\addfeature{forceyes}
active we get an *unexpected* result: small caps but no negative squeeze.
(Similar results occur if we toggle the "=force" lines with the "=yes" lines, but the larger project of which this is the MWE uses the force key.)
Clue: A CLD with a feature defined via fonts.handlers.otf.addfeature doesn't seem to have this problem:
==============
\startluacode
local function squeeze(tfmdata)
for k, v in next, tfmdata.characters do
v.width = 1.75 * (v.height or 0)
v.depth = 1.75 * (v.depth or 0)
end
end
local specification = {
name = "sqtfm",
description = "test",
manipulators = {
base = squeeze,
node = squeeze,
}
}
fonts.handlers.otf.features.register(specification)
fonts.handlers.otf.addfeature {
name = "stest",
type = "substitution",
data = {
a = "X",
b = "P",
}
}
\stopluacode
\definefontfeature[forceno]
[mode=node,
script=latn]
\definefontfeature[forceyes]
[mode=node,
script=latn,
% % smcp=force,
sqtfm=force,
stest=force]
% % smcp=yes,
% sqtfm=yes,
% stest=yes]
\showglyphs
\startTEXpage[offset=1em]
\definedfont[texgyretermes-regular*forceyes]
% \definedfont[texgyretermes-regular*forceno]
% \addfeature{forceyes}
abcdefg
\stopTEXpage
==============
So only the local-function feature appears to exhibit this inconsistency.
What is the explanation for this inconsistent behavior?
Is there a way to get the expected result for \addfeature etc.?
Thank you in advance.
Best wishes
Idris
--
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523
[-- Attachment #1.2: Type: text/html, Size: 5859 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
___________________________________________________________________________________
next reply other threads:[~2023-08-20 15:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-20 15:33 Hamid,Idris [this message]
2023-08-20 15:45 ` [NTG-context] " Hans Hagen
2023-08-20 19:10 ` 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=a20b95b3-7d75-49d2-bcb3-8e9f45fd21b0@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).