Re: largeop and stretchy ops

> Hi Shyjan,
> 
> > it seems to me that the same operator having both largeop and stretchy
> > specified is either conflicting or redundant. for example,
> > <mo>&Vee;</mo> has by default both largeop and stretchy to be set.
> 
> It seems a little weird to me too.  I guess I didn't know or have
> forgotten there are some operators with both properties set.  I'll ask
> Neil Soiffer about it, since he did most of the work on the operator
> dictionary.  
> 
> However, I thought of one practical consequence of setting both
> attributes.  Namely, if you set largeop, and you are in displaystyle,
> then the larger size would be the minimum size of the operator -- it
> would stretch to cover larger boxes in the same mrow, but if the large
> size already covered everything, it would just display at that size.
> If you didn't set largeop, then it would stretch if anything larger
> than the normal size were in the same mrow.
> 
> But I agree that normally it seems like things either have larger
> sizes, or the stretch, but not both, and in the WebEQ operator
> dictionary, I see I don't set stretchy for things like contour
> integrals.  I think that is definitely odd.
> 
> --Robert

Robert is correct in his reply.  'largeop' causes a larger size to
be used in displaystyle.  This is used for integrals, sums, etc.
Stetchiness is an orthogonal property, although it is mostly the case
that symbols with the 'largeop' property should also have the
the 'stretchy' property.  Exceptions are CirclePlus, CircleDot, etc.
Most examples of largeop but not stretchy (eg, contour integrals), are
probably bugs (the spec says they should be stretchy).  It is important
to remember that the ability of a renderer to make a character stretchy
is often a function of the fonts at the renderers disposal, and it would
not surprise me if contour integrals only came in one size in most fonts;
Mathematica uses one of three fixed sizes because that is what its fonts
supports.

Actually, there is one other thing property that I don't think is mentioned
in the spec.  It is kind of subtle.  Normally, stretchy chars should grow
to be as large as the largest box in the mrow.  However, if you have (eg)
nested sums with limits, it looks better if the limits are not included
in the size calculations so that all of the summation signs are the same
size.

	Neil Soiffer

Received on Tuesday, 8 August 2000 16:30:46 UTC