|
Subject: Re: DSSSL Design Question From: "James Clark" <jjc@xxxxxxxxxx> Date: Wed, 18 Jun 1997 13:07:30 +0700 |
> From: Vivek Agrawala <vivek@xxxxxxxxxxxxxxx>
> To: dssslist@xxxxxxxxxxxxxxxx
> Subject: Re: DSSSL Design Question
> Date: Wednesday, June 18, 1997 4:33 AM
>
> James Clark wrote:
> >
> > Since you can declare your own characterstics, why aren't they
sufficient?
> >
> > I think it would desirable to allow #f instead of a public identifier
in
> > declare-characteristic, to mean that this isn't a characteristic that
has
> > semantics that should be passed to the formatter, but rather it's just
being
> > used to pass information down.
> I like this idea. It would improve the flexibility of DSSSL.
>
> Can such characteristics be handled completely by the implementation?
> With the current Jade, user-defined characteristics require
> some modification in the backend(s).
At the moment if you declare a characteristic with a public identifier that
Jade doesn't know about, you can still use it to pass information down.
This is just a convenience to make to clear that you don't intend there to
be any formatting semantics associated with the characteristic.
> What are the advantages of "First Class Modes" over the
> "Not For Formatter Characteristics" ??
You can only use inherited-c inside the specification of a characteristic.
It's not legal to do something like:
(element p
(if (equal? (inherited-foo) 'bar)
(make paragraph)
(make sequence)))
This is because inheritance works on the flow object tree, and outside of a
characteristic specification you don't know where you are in the flow
object tree.
On the other hand there's no such restriction with first class modes.
James
DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| Re: DSSSL Design Question, Vivek Agrawala | Thread | Re: DSSSL Design Question, Vivek Agrawala |
| Re: Constructing HTML links in -t s, James Clark | Date | Re: collation, James Clark |
| Month |