Re: Font changes

A couple of thoughts:

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.

2)  In response to

>Fonts have several orthogonal attributes such as weight, slant, size,
>family, color, encoding.  This list is not exhaustive.  We should make
>sure that whatever mechanism we have for changing a font attribute cleanly
>changes just that attribute, and doesn't reset other attritributes.
>Eg, changing the font weight to bold should not affect whether the font
>is plain, italics, oblique, red, green, etc.  We should also make sure that
>we can change all of the important attributes of a font.

and 

>So i agree it is advisable for there to be only one argument,
>and also i'd like to point out that a simple string for "font data"
>would be insufficient; you need to be able to set different
>attributes independently...

it seems to me to depend on what you mean by a "simple string". A
PostScript font dictionary is a string after all.  But, I take both of
your points.  I personally would like to keep to one argument.  But at
the same time, I don't want the number of internal schema to
proliferate, as it would if we introduced (mfontcolor ..),
(mfontencoding ...) and so on.

So let me suggest a refinement.  Consider

	(mfont "property: value; property: value; ..." arg)

as a general format.  Property could then specify things like

	color, weight, slant, family, encoding, etc

and would modify the current font only in the ways specified.  
In this way, one could easily do things like turn on bold for a
character, while at the same time, it ought to be general enough to
handle most anything.

Some good alternatives:

	1) Permit only one property/value pair in the argument.

	   Pro: simple to parse
	   Con: requires lots of nesting for complete font changes

	2) Fix the order of the properties, and list them all in every
           font statement, with mostly null entries.  i.e.

	   (mfont ";;bold;;;" arg) or (mfont "Helvetica;slanted;;;;" arg)

	   Pro: simple to parse, more terse, looks like a bit mask
	   Con: one more obscure calling syntax to remember

	3) The compromise position.  Introduce some new internal
           schema for complicated things like font families and
           encodings, and use the schema given above for weight, slant
	   color, etc.

Robert