RE: Future of DSSSL: What about PDF?

Subject: RE: Future of DSSSL: What about PDF?
From: Avi Kivity <Avi@xxxxxxxxxxxxx>
Date: Sun, 7 Mar 1999 09:45:52 +0200
On Saturday, March 06, 1999 21:52, Brandon Ibach
[SMTP:bibach@xxxxxxxxxxxxxx] wrote:
> 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

I prefer a single interface in the implementation language, then wrappers
for the various interface technologies. It's always easy to add a wrapper,
but getting stuck with CORBA or DCOM or RMI where you don't have them (say
your new cell phone which uses dsssl to write to its 16x4 char cell screen)
may be a pain.

> 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.

Probably.

>    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

You can't do this with the most general of flow objects -- general-indirect.
It calls a dsssl procedure. It encapsulates the entire dsssl model.

> 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).

Yes there is.

Advanced rendering engine sends request.
Dsssl styling engine says: here you go, but I need such-and-such fo's page
number.
Advanced rendering engine does some rendering, figures out the page number,
and re-sends request.
Dsssl styling engine says: ok, here's some more data, plus all these fo's
have also changed. Call me again if the page number of that previous fo
changed.
Advanced rendering engine is now satisfied and presents the rendered data.

> 
> 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.

Again, general-indirect defeats this, since the formatting of date/time
could change page numbering, which can be the kernel of a generated object,
which can affect further processing in an arbitrary manner (including
changing layout -- a loop?).

For a concrete example,

(general-indirect-sosofo
    (lambda(n)
        (make sequence
            color: (if (odd? n) red blue)
            (literal (format-number n "1"))
        )
    )
    (page-number)
)

This can't be implemented unless the formatter has access to the (a?) dsssl
engine.

---
"The only words which have meaning are the last ones spoken"


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread