Re: Future of DSSSL: What about PDF?

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Quoting Avi Kivity <Avi@xxxxxxxxxxxxx>:
> On Saturday, March 06, 1999 21:52, Brandon Ibach wrote:
> >    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 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.
> 
   Agreed.  I wasn't necessarily saying we should make <insert your
favorite distributed component technology here> a required part of the
process, but that some type of well-defined, standardish mechanism
could be an important element.

> > 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).
> 
> 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.
> 
   Sounds like a horribly inefficient process, even to just maintain
the state between the rendering engine and the DSSSL engine.  So, what
happens when there's *no* connection between the engines?  In other
words, when the rendering engine simply receives a FOT.
   As far as your comments about general-indirect, I admit I need to
get more familiar with that part of the spec.  However, I'm not sure
of the relevance of it.  Of course, a sosofo that is designed to tie
the formatting process back into the DSSSL engine would need some
coupling between the two engines.  But, what if we designed the FO
system such that the formatting engine would have all the information,
at a high enough semantic level, to make the decisions itself?
   Consider, for a moment, the ability to specify headers and footers
in a simple-page-sequence.  Why have this ability?  Couldn't you just
have the DSSSL engine spit out the FOs for the header, then the FOs
for the body of the page, then the FOs for the footer, then do it all
over again for the next page?  Of course not, because that would
require the DSSSL engine to know exactly what content will be on each
page, and determining that requires the abilities of a formatting
engine.  So, we have a flow object (s-p-s) which has a *higher-level*
construct for specifying that each page has certain content for the
header and footer, and the formatter can arrange for it and take it
into account when fitting the flow of content to each page.
   So, as we encounter more complicated formatting needs, why not
simply create higher-level FOs to express these needs?  Yes, it may be
difficult to produce very general FOs at higher levels, but that's the
nature of more specialized needs and tasks.  With a well-designed
mechanism for extending the FO palette, this could provide all the
flexibility we could ever need without requiring a complicated
coupling of the styling and formatting engines.

-Brandon :)


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