Re: Preventing In-line Math Typesetting From Being Scaled Down in Text
- To: mathgroup at smc.vnet.net
- Subject: [mg120624] Re: Preventing In-line Math Typesetting From Being Scaled Down in Text
- From: John Fultz <jfultz at wolfram.com>
- Date: Sun, 31 Jul 2011 07:27:10 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Reply-to: jfultz at wolfram.com
On Sat, 30 Jul 2011 06:03:25 -0400 (EDT), blamm64 wrote:
> On Jul 27, 6:15 am, John Fultz <jfu... at wolfram.com> wrote:
>> Looks like there's a minor bug in the updating mechanism. Perhaps this
>> is what you ran into. If, after following my procedure, you save,
>> close, and reopen the notebook, you'll see that the change has taken
>> effect.
>>
>> Core.nb is inside the Mathematica layout, but it's generally not a good
>> idea to be changing things there. If you're hoping to make the change
>> globally for all notebooks on your system, let me know and I can walk
>> you through that procedure. However, doing so will not change the
>> notebook when viewed on somebody else's system, where as the Format-
>> >Edit Stylesheet... change will persist with the notebook regardless of
>> which system it's viewed on.
>>
>> Sincerely,
>>
>> John Fultz
>> jfu... at wolfram.com
>> User Interface Group
>> Wolfram Research, Inc.
>>
>>
>> On Tue, 26 Jul 2011 14:10:44 -0400, Gregory Lypny wrote:
>>> Hello Mr. Fultz,
>>>
>>> Tried but it didn't work. I executed the command in the stylesheet
>>> notebook corresponding to the notebook I'm working with. Perhaps I've
>>> misunderstood. Also, not sure where to find Core.nb. Is it in the
>>> application package?
>>>
>>> Gregory Lypny
>>>
>>>> On Fri, 22 Jul 2011 19:46:07 -0400 (EDT), Gregory Lypny wrote:
>>>>> Hi everyone,
>>>>>
>>>>> When I include fractions as inline math typesetting, they are
>>>>> scaled
>>>>> down
>>>>> to fit the effective line height of the cell. How can I prevent
>>>>> this
>>>>> or,
>>>>> I guess, make the line height automatically expand to accommodate
>>>>> the
>>>>> math? If my regular text in the cell is 12-point times, I'd like
>>>>> all
>>>>> math variables that are not subscripts or superscripts to be 12-
>>>>> point
>>>>> as
>>>>> well.
>>>>>
>>>>> Incidentally, other big typeset objects like matrices are not
>>>>> scaled
>>>>> down, or at least they down't appear to be.
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Gregory
>>>>>
>>>> If you look in Core.nb, you'll find a style called "InlineCell".
>>>> This
>>>> style is
>>>> automatically applied to all inline cells everywhere. One of the
>>>> options it has
>>>> set is:
>>>>
>>>> ScriptLevel->1
>>>>
>>>> This is what's causing the behavior you're seeing. You can override
>>>> this with a
>>>> custom stylesheet. For example, in a given notebook, you can make a
>>>> private
>>>> override by doing Format->Edit Stylesheet..., and pasting and
>>>> interpreting the
>>>> following cell expression at the end of the resulting stylesheet
>>>> notebook:
>>>>
>>>> Cell[StyleData["InlineCell"], ScriptLevel->0]
>>>>
>>>> Sincerely,
>>>>
>>>> John Fultz
>>>> jfu... at wolfram.com
>>>> User Interface Group
>>>> Wolfram Research, Inc.- Hide quoted text -
>>>>
>> - Show quoted text -
>>
> Thanks John! Is there anything similar for Input cells
> (StandardForm)? Often, I prefer to enter math Input in 2D, and if I
> enter a 2D Piecewise, and one or more lines of the Piecewise have
> fractions and/or square roots, the font ends up being really tiny (for
> me). So some similar setting for Input (StandardForm) to force the
> font size to be the same regardless of position would be helpful to
> me.
>
> -Brian L.
Here's a little tutorial on what's going on:
There are three options which control how scripts and fractions shrink.
* ScriptMinSize - this is the minimum size (in points) of the font which will
ever be used inside of a script/fraction.
* ScriptSizeMultipliers - this is the multiplier is used each time you add a
script/fraction level. I.e., by default, fonts shrink by a factor of .71 for
each script level.
* ScriptLevel is the option which determines how deep the script is. This is
set by Mathematica automatically, but it is possible to override it via the
Option Inspector or in a stylesheet.
So, the resulting font size is going to be:
Min[
Max[ScriptMinSize, ScriptSizeMultipliers^Max[ScriptLevel-1,0] *
currentFontSize], currentFontSize]
Which means ScriptLevels of 0 and 1 never shrink, but 2 and greater do. It's a
bit more complicated than this because you can pass ScriptSizeMultipliers a
list...see the documentation for details...but this describes the default case
accurately.
ScriptLevel is 0 in Input cells and 1 in inline cells (the latter behavior being
determined from the stylesheet). In nested fractions it always increments by 1.
In nested scripts, it always starts at least at 2 in the outermost script, and
then increments by 1.
ScriptLevel can also get set automatically by Mathematica a few other times.
One of them, as you're running into, is inside of a GridBox. The front end
allows the ScriptLevel to be incremented from 0 to 1 (but not greater than 1)
when inside of a GridBox. That's why you're seeing Piecewise behave the way it
does.
This means that first-level fractions, by default, don't shrink in Input cells
because their ScriptLevel is 1, but first-level fractions in inline cells and
grids shrink because their scriptLevel is 2.
Possibilities...
* You could get rid of shrinking entirely by setting
ScriptSizeMultipliers->{1.}, or stop the first-level shrinking by using
ScriptSizeMultipliers->{1.,.71}. You can also set ScriptMinSize to an
outrageously large value. You could set this at global scope, or on the
StandardForm style.
* It's possible to target Piecewise specifically by changing the "Piecewise"
style.
Devising a solution for this was slightly tricky, as I wanted to preserve
shrinking behavior, but not for top-level fractions. Here's what I came up
with:
Cell[StyleData["Piecewise"],
FractionBoxOptions->{BaseStyle->{ScriptLevel->1}}]
This doesn't shrink nested fractions, but it does shrink scripts, and itacts
pretty reasonably with fractions inside of scripts.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.