Re: display list attributes revisted

At 1:09 PM 7/17/96, rminer@geom.umn.edu wrote [excerpted];

>Does anyone have any thoughts on how layout schema attributes should
>be represented in the display list?  
>....
>Here are a couple of proposals.  Note they certainly relate to our
>earlier discussion of how a font change mechanism might work.


Ultimately we will need two kinds of constructs related to these:

- specify the attributes for an individual layout schema (but not for
  its operands);

- change the rendering style (e.g. font) for all parts of a subexpression.

I'll call these "attribute" and "style" changes, respectively.
Here are my opinions and thoughts on them:


Style changes should be done with something like your proposal 2, since
they apply to all parts of a subexpression. (Ultimately this should be
made compatible with CSS, if it becomes standard. This may mean that it
gets a bit more complex; for example, the style options may come in
"groups" which can be changed as a unit. If your style names can be
strings and your style values can be lists, like in CSS, your code will
probably be easily made compatible with that.)

I think a style-change construct is properly a layout schema.


Attributes naturally fit your Proposal 1 better, since that makes it
clear that they apply only to one layout schema instance, not to its
operands (even if they contain the same type of layout schema).

However, the attribute list is not really optional, and it can't really
allow default-valued attributes to be left out, unless the renderer has
access to the same dictionary as the parser does, which strikes me as
undesirably non-modular. Rather, the parser will copy, and perhaps
modify, the dictionary's default-attribute list, and attach that to
each layout schema.

Given this, the attribute-list need not be messy to parse -- it can be a
required last element of every display list, and it can itself have a
list structure, namely a list of pairs (2-element lists) of attribute
names and values.

I'm assuming that the display list will generally be an internal data
structure, and can use pointers to shared structures, so this will not
be "wasteful" in any significant way.

If it turns out that the display list will be a data type sent from one
program to another, we'll have to reconsider how to represent this kind
of thing.

Admittedly, this makes it a lot more painful to type example display
lists by hand. I don't see a good way around this right now. As a kluge
for a demo (which could be made official if we did decide to give the
renderer access to the real dictionary too), you could allow the lists
to leave out default-valued attributes according to a very simple
(fake) "dictionary" whose defaults depended only on the type of layout
schema. And you could allow them to be optional if you can tell whether
they're there, i.e. if you can distinguish them from normal arguments.
Maybe they should have a special syntax, so they can be distinguished,
e.g. be lists wrapped in [] rather than ().

- Bruce