On 4/5/2014 9:58 PM, Philipp Gesang wrote:
···<date: 2014-04-05, Saturday>···<from: Hans Hagen>···
On 4/5/2014 4:37 PM, Philipp Gesang wrote:
Hi Hans,
when combining e.g. certain number substitutions like onum and
pnum or tnum and lnum, node mode seems to work fine. However,
those do have value in math mode as well which node mode does not
currently support. For comparison, here is a test file:
https://bitbucket.org/phg/lua-la-tex-tests/raw/93745dba31e23febb02191c039dea2de743ce77a/cnt-features-8-combined-num.tex
Is there a way to define a font with the combination of, say tnum
and lnum that will work in math mode? If not, are there plans to
implement it in the future?
basemode will always be limited because there we create static glyph
sets; so. for complex substitutions node mode is the method to use
what do you mean with math mode in this case; in math a digit is
different from a digit in text mode; i think that if one uses *num
digits we're talking text mode
I’m just relaying a question of a user who wishes to use those
combined lnum+tnum digits in math mode.
of course in context we can support whatever we want because we're not
bound to rules, but the question is: does it make sense;
Ultimately I can’t judge that, the problem description does seem
valid though: http://tex.stackexchange.com/q/165238/14066
In math mode characters are organized in categories, e.g. letters are
grouped in alphabets. Now imagine that we start applying font features,
does that mean that a 'a' should become a small caps 'A'? And when are
features applied? Math is a tree and not per se sequential, so how about
ligatures? Ok, digits might be something special but even then, just
swapping one '1' for another one that is not math aware and then is
combined with other math characters (lik ein scripts) can have weird
side effects. This is not something generic.
So, the only way to deal with that properly is to define a font where
certain rendering is replaced by another but in the same slot. Even then
one really needs to know if the font is suitable for it. I guess that
such oldstyle thingies are mostly for simple math that stays close to
text, but even then.
In context I'd certainly not deal with that by features directly also
because the *num properties are not always implemented the same (we have
a mechanism for combining fonts anyway).
If someone realy wants features applied to math (maybe after the math is
processed, then i can imagine that the node font handler is hooked into
the mlist_to_hlist callback so that they are applied afterwards. In any
case it's very macro package dependent.
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
| 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://tex.aanhet.net
archive : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
