[dev-context] unicode-math

Philipp A. trueflyingsheep at googlemail.com
Thu Feb 11 12:49:52 CET 2010

2010/2/11 Hans Hagen <pragma at wxs.nl>

> On 11-2-2010 12:12, Philipp A. wrote:
>> 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}
> i can look into it ... but it's up to you to provide some test files first
> so that we can determine to what extend we go

if you want me to provide test files, shall i simply think of complicated
cases and put them togeter between \starttext and \stoptext in a tex(t)file?

>    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?)
> well, we could also support display but we might pose some restrictions
> 2a / b
> vs
> 2 a/b

i have no idea how to do the grouping. openoffice avoids the stuff mostly,
but i can’t wrap my mind about the rules. when writing stuff with openoffice
(i seldomly do it), i just avoid braces and fix all display errors

    3. you mean “\√” yields “√”? of course! it’s like a “&” or a “\”, then.
> indeed, but introducing more commands like \√ might not be the way to go as
> we try to get rid of & etc being special (i've even be thinking os some
> special unicode char, maybe a private pair, for $ $ replacement

ok, that’s an interesting direction to go. i didn’t try context too hard,
because i write exams in a week and shouldn’t be writing this but rather
learning biochemistry ;)

    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?
> indeed and as with cambria it's microsoft currently leading the way .. in
> my opinion the tex math community lost the lead long ago so we have to
> follow now (stix is a good example ... we could probably easily test those
> fonts in mkiv but no one cares)
> Hans

what do you mean with “no one cares?” no one cares about context or about
stix or about context testing stix?

it’s sad that the inferior approach gained the lead, but we don’t lose our
advantage: we don’t have to make compromises in the layout beause noone
expects a document updating in real time when a word is inserted in the
first paragraph. we are the ones with the fine-grained control over every
aspect of our typesetting and so we won’t be obsoleted by word.

microsoft doesn’t like open source, but everyone owning windows can use
cambria math and since the microsoft document above shows no patented stuff,
we can use that, too, if we like it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ntg.nl/mailman/private/dev-context/attachments/20100211/b3e7b264/attachment-0001.html>

More information about the dev-context mailing list