Re: Future of DSSSL: What about PDF?

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

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