Re: [NTG-context] [fontloader] does base mode support combining substitutions?

On 4/5/2014 9:58 PM, Philipp Gesang wrote:

·········

...

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/93745dba31e23febb02191c039dea...

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