Subject: Re: Future of DSSSL: What about PDF? From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Sat, 6 Mar 1999 13:51:32 -0600 |
Quoting Avi Kivity <Avi@xxxxxxxxxxxxx>: > I think the best way to proceed is to write a formatter+text backend which > supports all flow objects, then generalize it to more capable page > description languages. > The formatter must support two interfaces: > - an interface to the front-end that receives sosofos and requests > evaluation of expressions > - an interface to the back-end to send output and request measurements > I don't think the formatter can work using unidirectional communications > with either the front-end or the back-end, so no independent interface > languages here. > A couple of comments. First, I think the basic idea here is valid (of a two-way interface for coupling the formatter to the DSSSL engine). However, I see no reason why an independent interface mechanism (CORBA, DCOM, RMI, etc) could not be used. I would think a callback mechanism would be the way to go. As the DSSSL engine would generally be initiating and "driving" the processing, it would most likely call a standard interface on the formatter and provide a callback mechanism so that the formatter can request the services of the engine, as well. Beyond all this, however, I'd like to find out what you all think of an alternative to the closely coupled formatter and engine. I recall that we had a discussion along these lines some months ago, and one of the alternatives was to create higher level FOs that could "encapsulate" some of the more complicated formatting tasks which might otherwise require such a coupling with the formatter. I see two main advantages to this. First, we avoid the complexity of coupling the formatter to the engine. Second, and this is one that the coupling solution can't even touch, is the fact that it allows for a complete separation of the styling and rendering processes. As an example, what if you're dealing with a client/server situation where you've got the DSSSL engine doing the styling on the server, and an advanced rendering engine on the client, and there's no way for the two to communicate beyond a simple transfer protocol (such as HTTP). This could well be the case for a client behind a firewall. Another possibility would be a situation where the DSSSL processing is done in batch mode, but the rendering is done on demand, possibly including dynamic information, such as the current date, each time. This idea is, of course, based more on general design concepts than on practical knowledge of the problems which these approaches would need to solve, so I'm certainly wide open to any comments on the feasibility of this idea. -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Future of DSSSL: What about PDF, Avi Kivity | Thread | RE: Future of DSSSL: What about PDF, Didier PH Martin |
RE: Future of DSSSL: What about PDF, Didier PH Martin | Date | RE: Future of DSSSL: What about PDF, Didier PH Martin |
Month |