Re: unicode integral sign

[Aditya Mahajan <adityam@umich.edu>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2441 bytes --]

On Sat, 29 May 2010, Taco Hoekwater wrote:

> Aditya Mahajan wrote:
>>  On Sat, 29 May 2010, Yury G. Kudryashov wrote:
>> 
>> >  Taco Hoekwater wrote:
>> > 
>> > >  Yury G. Kudryashov wrote:
>> > > >  Hi!
>> > > > 
>> > > >  I try the following:
>> > > > 
>> > > >  \starttext
>> > > >  $∫_a^b \int_a^b$
>> > > >  \stoptext
>> > > > 
>> > > >  In the first case, the integral sign is below the text. Should I use
>> > > >  another font, or is it possible to fix with the default one?
>> > > 
>> > >  It is possible to fix this. The reason for the odd placement is that 
>> > >  the
>> > >  'math code' of ∫ is not set up properly (and it probably isn't either
>> > >  for some other bare Unicode characters). To fix the hard way, add this
>> > >  at the top of your input file:
>> > > 
>> > >  \Umathcode `∫ = 1 0 `∫ % 1 == \mathop, 0=fam0, ∫=glyph
>> >  Is there any documentation on char-def.lua file format? If I'll 
>> >  understand it, I'll send a patch for the symbols I use.
>>
>>  Not a complete documentation, but some explanation is here
>>
>>  https://www.tug.org/members/TUGboat/tb30-2/tb95mahajan-cmath.pdf
>> 
>> >  Currently I have no idea why the following strings in char-def don't 
>> >  work.
>> > 
>> >  [0x222B]={
>> >   adobename="integral",
>> >   category="sm",
>> >   cjkwd="a",
>> >   description="INTEGRAL",
>> >   direction="on",
>> >   linebreak="ai",
>> >   mathspec={
>> >     { class="nothing", name="intop" },
>> >     { class="limop"  , name="int"   },
>> >   },
>> >   unicodeslot=0x222B,
>> >  },
>> > 
>> >  Replacing mathspec=... with mathclass="limop", mathname="int" seems to 
>> >  work (copied from n-ary summation).
>> > 
>> >  BTW, in both solution ∫_a acts like \int\limits_a, not \int_a.
>>
>>  In plain TeX, this is taken care by
>>
>>  \mathchardef\intop="1352 \def\int{\intop\nolimits}
>>
>>  Can I do the same in luatex without active characters?
>
> No, but it is a useful extension to consider. There are internally
> three types of large operators, for 'limits', 'nolimits' and
> 'displaylimits' and this bothers me a bit. We can't reasonably
> extend the old primitives, but \Umathcharcode c.s. could be made
> to accept extra values '9' .. '11' for those three types without
> any compatibility problems.  I'll add to the tracker.

Thanks. That will make all the int (and sum) setup much simpler.

Aditya

[-- Attachment #2: Type: text/plain, Size: 486 bytes --]

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