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, ETC. 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 modes 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.) or whatever? 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 formalism. PatrickReceived on Thursday, 27 June 1996 21:49:55 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC