i’m quite excited to find out that most of what i want is already in mkiv!
regarding the problems you mentioned:
1. the super/subscripts could be interpreted like x²³₄₅ → x^{23}_{45} or
couldn’t they? if you want to do more complex stuff (more than one level of
super/subscripting), the super/subscripts are only for the last level:
x^{2³}_{4₅} → x^{2^3}_{4_5}
2. maybe the use of unicode fractions and sfrac as a fallback would be
nice for inline math: 4 ⁄ 5 → ⅘, 8 ⁄ 9 → \sfrac89. for display it would
be {4 \over 5} and {8 \over 9} (maybe i don’t get your point: isn’t \over
context’s way of doing fractions?)
3. you mean “\√” yields “√”? of course! it’s like a “&” or a “\”, then.
4. you mean
this<http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v2.pdf>.
nice thing, worth more than one look! maybe really the direction of the
future?
5. the parentheses like you suggested are in the above document, too.
thank you for the nice answer,
phil
PS: with the use of a compose key, the input of math symbols is quite
straightforward: <compose>45 → ⅘, <compose>/= → ≠, …
2010/2/11 Hans Hagen <pra...@wxs.nl>
> Hi Philipp
>
> context in combination with luatex is quite the way to go for me, but i
>> have
>> one thing that i would love to see inside context:
>> unicode-math<http://github.com/wspr/unicode-math>!
>>
>> the guys there are making a good job of mapping tons of unicode sequences
>> to
>> latex commands, so we should really profit from this project.
>>
>
> i once took a look at the tables of stix and ams and then decided to follow
> another route
>
> - we collect all info in char-def, also math related info
> - we want to be able to support field specific setups (similar to what
> openmath does) and the machinery is mostly there already
> - we don't follow latex although we try to be ams math compatible
> - support like that is not that much related to \commands (and mapping
> them) as we already support direct mapping etc
> - we have a different way of organizing the math symbols and alphabets in
> context (mkii is more traditional)
>
>
> is it possible to integrate it into context or to create a package for
>> this
>> purpose?
>> i would love to write $y = x² ± 2µ ⇒ y ≠ √{α ⁄ 5}$, while still being able
>> to write $y = x^2 \pm 2\mu \Rightarrow y \neq \frac{α \over 5}$ or any
>> combination of the two.
>>
>
> sure, but it's unlikely to happen before there is an lmtypewriter font that
> has those shapes so that i can see it on my screen (lm/gyre math) .. it's
> simply too painful to debug and we also need to be able to use such symbols
> in documentation
>
> there are a few problems:
>
> (1) $y = x² ± 2$ -> we had some discussion about remapping the superiors
> and didn't reach a conclusion yet (as it is only a limited set); this is not
> going to happen at the input level but will be done by analysing the math
> list (just as is done with other things), so here it's mostly a matter of
> making a decision
>
> (2) √{α ⁄ 5}$ -> the / (or \over) is somewhat special ... if / is inline,
> then it's ok but do we want something for display as well
>
> (3) in the above the root is somewhat special as it is the text root
> symbols and if we support that we should also provide escapes to get that
> literal one
>
> (4) at microsoft they came up with an input method that makes sense as well
> so maybe i will implement that one some day
>
> (5) the { } still do grouping but maybe we want ( ) and some automated way
> (as in mathml) to omit them if possible
>
> so, for me math is part of a bigger picture: mathml, alternative input, not
> per se sticking to tex conventions etc
>
>
> i would too love to participate in a project making this possible, but i
>> don’t know how to start coding (i could only write a preprocessor in
>> python
>> doing this, but that would be rather a workaround than the true thing.)
>>
>
> the right way is adding missing info to char-def.lua and that happens under
> tight control (read stepwise as we need to test things); so, if you find
> missing mapping, just collect them and let us know (normally aditya does the
> checking of the math symbols)
>
> so there is not so much coding needed but mostly identification (the same
> is true for symbols that are someplace in fonts but not yet mapped in the
> virtual font mapper) so that's the place to start looking
>
> Hans
>
>
> -----------------------------------------------------------------
> Hans Hagen | PRAGMA ADE
> Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
> tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
> | www.pragma-pod.nl
> -----------------------------------------------------------------
>
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
