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

[Hans Hagen <pragma@wxs.nl>]

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
___________________________________________________________________________________