[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

**To**:*math-font-discuss@cogs.susx.ac.uk***Subject**:**Re: new delimiters****From**:*Jan Michael Rynning <jmr@nada.kth.se>***Date**: Fri, 20 Aug 93 17:59:11 +0200

Michael Downes writes: > The gap of six points between the 4 smallest sizes of the delimiters > such as ()<> seems too large (it is possible for two side-by-side > delimited formulas whose heights differ by <1pt to have delimiters > whose heights differ by 6pt); maybe there should be some extra That only happens if you use \left and \right and leave it to TeX to decide upon the size of the delimiters. I only do that when there is no other alternative (parentheses around large matrixes, large braces in cases, ...), because the delimiters which \left and \right gives you are often too large. > interpolated sizes at the small end of the spectrum. But there is an > element of compromise involved: if the gap between sizes were only > 2pt, say, then two side-by-side formulas of height 23.5 and 21.5 would > then get delimiters of height 22pt and 24pt where formerly they both > would have delimiters of height 24pt, and some people might prefer to > get same-size delimiters rather than get a more exact height match for I find it very distracting when the size of the delimiters varies from one formula to the next or even within one formula, for no apparent reason. If I see two fractions in a display formula, e.g. \frac{1}{g} and \frac{a}{c}, and there are parentheses around them, I expect the parentheses to have the same size, because I consider the fractions to have the same size, even though `1' is higher than `a' and `g' is deeper than `c'. > the first formula. Uh-oh, does this mean that the math encoding for > the delimiters would have to vary according to publisher preferences?! I'm involved in the typesetting of two mathematical journals: Acta Mathematica and Arkiv f\"or matematik. Both of them try to be as restrictive as possible when it comes to delimiter sizes. Basically they use three sizes of delimiters: 1. (...) around a part of a formula which is just one line high 2. \biggl(...\biggr) around integrals, sums, fractions, ... in display formulas 3. \left(...\right) around large matrixes in display formulas (well, this isn't actually a ``size'' but they all use the same pieces from the font no matter how large you make them) So, I don't think cmex has to few delimiter sizes. I would rather say it has too many, though I must admit that we have used one or two other sizes for a few unusual constructions. > Or, maybe it means that the issue of choosing larger sizes of > delimiters is orthogonal to encoding issues: the new math encoding > should perhaps only specify the font position of the first delimiter > in the nextlarger chain and somehow leave the mechanism for getting The macros for accessing the delimiters (\big, etc.) make two assump- tions: 1. All delimiters can be be accessed through their delcode (basically the position of the smallest delimiter of that type, defined in TeX macro files like plain.tex) and the nextlarger chain in the font. 2. The font has delimiter sizes which match the \big, ..., \Bigg sizes specified in the TeX macro file which defines \big, ..., \Bigg. The first assumption corresponds to what you propose. The second one puts font dependencies into the macro definitions, and I would prefer not to do that. I think it would be better if we could make the \big, ..., \Bigg sizes available as font parameters. > the larger sizes open to local variation. In other words, suppose > someone wants to create a gmex10 font tailored for use with Garamond, > and they want to add extra interpolated sizes of ()<>; as things > currently stand they would not be able to do this without departing > from the standard encoding, unless the standard encoding were to > reserve extra font positions for this possibility. Or something to > that effect.

- Prev by Date:
**Arrow heights** - Next by Date:
**No Subject** - Prev by thread:
**Re: new delimiters** - Next by thread:
**Re: new delimiters** - Index(es):