Re: Too Tiny Fonts! in fractions, summations, etc.
- To: mathgroup at smc.vnet.net
- Subject: [mg14636] Re: Too Tiny Fonts! in fractions, summations, etc.
- From: "P.J. Hinton" <paulh>
- Date: Wed, 4 Nov 1998 13:47:05 -0500
- Organization: "Wolfram Research, Inc."
- References: <70k2t2$ek2@smc.vnet.net> <70r8ql$sbv@smc.vnet.net> <71l000$9bl$3@dragonfly.wolfram.com>
- Sender: owner-wri-mathgroup at wolfram.com
On 2 Nov 1998 yxz11 at my-dejanews.com wrote:
> I met this problem after changing my screen resolution. It's a pain in
> the back to change the font. Until now, I still can't change the font
> in Option Inspector.
>
> The solution provide by Wolfram is rediculous, should I become a expert
> on formatting then I can read my notebook?
It is not necessary to become an "expert on formatting", but it wouldn't
do you any harm to become familiar with the way configuration and
customization is handled with the version 3.0 front end.
With a grasp of just a few fundamental principles, you would probably be
able to understand why some of the changes you tried to make do not
seem to have any effect. It would also become clear what you do need
to do to customize things to your liking.
The first thing to note is that front end settings, notebook settings,
settings for individual cells, and settings for pieces of cells are all
specified through options expressed as replacement rules.
Next, keep in mind that notebooks can be represented as a Mathematica
expression which contains a list of cells. Options can be specified as
a second argument:
Notebook[{list of cells}, options]
Each can also be represented a Mathematica expression. The contents in
the first argument store what is shown in the cell. The second
argument is a style which specifies the structural function (title,
section, kernel input, caption).
Cell[contents, style, options]
The appearance associated with a given style is specified in a style
sheet notebook that contains prototype cells. Each prototype cell
contains options that will be inherited by a cell uses that given
style.
Options not specified for a given level are always inherited from a
higher level. The hierarchy from highest to lowest.
Global (stored in Front end init.m)
Style Sheet (specified by StyleDefinitions option in notebook)
Notebook (stored as options to Notebook expression)
Format type (explained below)
Cell (stored as options to options to Cell expression)
Local modifications (options to a StyleBox, for example)
Most cells store just plain text content in TextData[] expressionswith
local modifications induced by StyleBox[] expressions.
Cell[TextData[{"plain ",
StyleBox["italic", FontSlant -> "Italic"]}], "Text"]
However, the representation of two-dimensional typeset forms
(StandardForm and TraditionalForm) requires the use of box expressions.
Cell[BoxData[SqrtBox[SuperscriptBox["a","2"]]], "Input"]
The front end knows whether to store your input in a box situation like
this depending on whether a given cell style's style definition has the
following option set explicitly:
DefaultFormatType
In the case of cell styles like "Input" and "Output", the settings are
DefaultInputFormatType and DefaultOuputFormatType, which you can adjust
from the front end menu commands:
Cell -> Defalut Input Format Type
Cell -> Default Output Format Type
Settings for these are stored in an aggregate option that is named
CommonDefaultFormatTypes. Here are the default settings defined
globally.
CommonDefaultFormatTypes -> {"Input" -> StandardForm,
"Output" -> StandardForm}
If a format type is in effect for a given cell, options for this format
type, as specified in a style sheet, will override the cells set at the
option level.
This is why some people find it odd that changing the font used in the
Input style prototype does not seem to impact cells which use the Input
style. It is because the prototype for the format type (StandardForm)
has an explicit option that sets the font to Courier. To change the
default font used for this cell style, you would have to change the
default font in the StandardForm prototype. This may be the problem
you are encountering in your situation.
This separation of content function (style name) and presentation (style
sheet) is a practice that is adhered to in other markup languages, be
it LaTeX, HTML, or XML. It may be more difficult to deal with if
you're used to WYSIWYG word processors like Microsoft Word, but it in
the long run it is better approach because it leads to consistent
document design that can be adapted for different methods of
presentation, be it on a computer moitor, on-screen projection, or in
hardcopy form.
--
P.J. Hinton
Mathematica Programming Group paulh at wolfram.com Wolfram
Research, Inc. http://www.wolfram.com/~paulh/
Disclaimer: Opinions expressed herein are those of the author alone.