Re: Font changes
To: email@example.com, firstname.lastname@example.org
Subject: Re: Font changes
From: email@example.com (Patrick D. F. Ion)
Date: Thu, 27 Jun 1996 21:53:36 -0400
From firstname.lastname@example.org Thu Jun 27 21: 49:55 1996
The first point of Robert's last message on fonts seems to me very important.
It is necessary to be able to handle whatever the ordinary HTML will allow.
He must know the difficulties that might ensue by choosing an, in
principle, adequately general but badly fitting structural design. I
assume that he will watch for that.
>1) In regard to
>> I thought we were going to try and be compatible with font specifications
>> as used (planned?) in the rest of html. Is your proposal compatible with
>> normal html font specifications?
>my understanding is that the "display list" is output by the parser,
>and is not accessible to the author. Thus, in order to be compatible
>with HTML, the display list mechanism need only be general enough to
>provide the functionality required by HTML.
Addressed to point
>2) In response to
>>Fonts have several orthogonal attributes such as weight, slant, size,
If this display list is to have single arguments for font changes then
it is good that it will be only an internal data format. Is it the case
then that this is only entertained for deviations from the standard display
corresponding to display, text, script and scriptscript in TeX-style
composition? So that, say, the display list will have to have font
information like this for such things as are commonly put in
bold (vectors, dyadics, some bundles, etc.),
blackboard bold (reals, complexes, integers, etc),
script (Schwartz distribution spaces, Hilbert space names, etc.),
fraktur (Lie algebras, ideals, local rings, etc.)
Furthermore is, in conventional output, the sizing of special characters
considered as clearly varying along conventional lines, e.g. 10-7-5 point?
>So let me suggest a refinement. Consider
> (mfont "property: value; property: value; ..." arg)
This certainly sounds a general enough form, and begins to look like SGML
attribute lists too:
<mfont property1="value" property2="value" ... >arg</mfont>
Is there any significance to this? I suspect I have the wrong idea of that