Re: Is DSSSL Hard?

[Paul Prescod <papresco@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Dave Raggett wrote:
> I would like to understand DSSSL better, and like most people
> found the ISO spec too difficult to get anything beyond the
> roughest of understanding. I would be most grateful if you
> could help me with a few points.

What I can. I've been explicit that DSSSL's easy to get started but
there are lots of parts that are still hard to use!
 
> > (element BR (make paragraph-break))
> 
> Shouldn't this be a forced line break?  Is there a line-break
> command in DSSSL for text flows?

I'm not sure what you mean. Since we are dealing with formatting, you
usually just use whatever flow object gives you the formatting you want.
As such, I'm not sure what the difference is between a paragraph-break
and a line-break. They break the flow of text and insert a variable
amount of space between the line above and the line below. Everything
there is to know about Paragraph Breaks are at:

http://occam.sjf.novell.com:8080/dsssl/dsssl96/20452?DWEB_NAVHINTS=20471,0,4

The DSSSL spec. sections on flow objects are mostly fairly readable
except when you are doing difficult things. Maybe James will comment
more on why paragraph breaks are disparaged in the spec.
 
> How do font-postures work? I assume they combine together
> but what happens if the combination is not available, how
> does the font selection work?

I don't see any explicit fallback. "ISO DSSSL" wasn't designed for the
disorganized world of the Internet. There are three mandatory fonts
(serif, sanserif, and monospace) and you either stick to those or take
your chances. I think that even in DSSSL-XML, the solution to this
problem would probably be left to the other W3C groups already working
on it. Presumably the same problems afflict HTML, CSS, PDF etc.
 
> > (element IMG
> >   (make external-graphic
> >       entity-system-id: (attribute-string "src")
> >       display?: #t
> >       space-before: 1em
> >       space-after: 1em ))
> 
> I think this needs to deal with the presence of width/height
> attributes, and the padding and other properties. 

Sure. I didn't want to get into supporting every feature. The tables
alone would have taken me a decade! I just wanted to show that a basic
stylesheet is easy. There are external-graphic characteristics such as
scale: max-width, max-height, position-preference, span, etc. etc. I
would have to translate the HTML names for these things into the DSSSL
equivalent. Jon Bosak's handles alignment, but not sizing.

> How would
> I specify that I want the browser to show content early
> repainting it as image sizes are determined? Arena works this
> way while Netscape defers painting until image extents have
> been determined. This fine degree of control isn't possible
> with CSS, but should be with a richer style sheet mechanism.

You can declare a characteristic at the top (which would probably become
a "built-in" in DSSSL-for-the-web) which is "defer-painting?"

> I am acutely aware of the problems involved in formatting
> tables. Does DSSSL support the 2 pass mechanism for sizing
> (possibly nested) tables according to the content?

I believe the answer is yes and no. DSSSL allows you to "point to" a
table automatic sizing method through a public identfier. In other
words, people are supposed to publish algorithms (not necessarily code,
but rigorous descriptions of algorithms) and if the table-auto-width
feature is enabled, and the DSSSL engine "supports" that algorithm
(where I suppose that "supports" might include dynamically fetching it
off the Web) then you get automatic table widths. Probably DSSSL on the
Web should specify one of these algorithms and allow others to publish
some as RFCs.

table-auto-width-method: is #f or a string specifying a public
identifier for the method to be used to determine the widths of columns.
This applies only if the table-auto-width feature is present. The
initial value is #f.

http://occam.sjf.novell.com:8080/dsssl/dsssl96/25298

12.6.27.4 Automatic Table-width Computation

This clause applies when the table-auto-width feature is enabled. 

The width of a column for which no width is specified shall be at least
as great as the maximum of the minimum possible widths of the content of
any table-cells that span exactly that column. 

NOTE 113: When a table-cell includes a paragraph for which the lines:
characteristic has a value of wrap, the minimum possible width of that
paragraph is determined in a system-dependent manner. It might, for
example, be the length of the longest word. 

If a table-cell spans more than one column, then the sum of the widths
of the columns that it spans shall be at least as great as the width of
the content of the table-cell. 

If a length-spec is specified for a column's width, then the column
shall be exactly that wide, and that length shall be used as the
display-size for any table-cells which span exactly that column. 

Other aspects of the width computation method can be controlled with the
table-auto-width-method: characteristic. 

http://occam.sjf.novell.com:8080/dsssl/dsssl96/25961
 
> There are hidden problems in specifying table style due to
> that fact that its not a tree - cells have two parents a
> row, and a column, then row groups and column groups. Some
> tables even drop the requirement that all cell boundaries
> are aligned on column boundaries. I have further found
> problems with mixtures of fixed and proportional widths
> for columns, especially when space is in very limited supply.

There are some DSSSL implementors on this list, so maybe they have some
experiences to contribute.
 
> Perhaps the mess can be hidden in specialized flow objects.
> How does DSSSL allow me to specify a non-standard flow
> object?  

(declare-flow-object-class Internal-name PublicID )

> I can envisage using Java to define a flow object
> with an API for driving it from DSSSL, can you enlighten
> me on how this works in practice?  

There are two current implementors in Java. Hopefully one of them will
pipe up about whether they dynamically load flow object classes. I'm not
sure if the interactions between flow objects are sufficiently simple to
make this easy. It may be possible, but let's say that your special
foobar flow object has a link in the middle of it. Let's say that a Java
class renders that flow object. There must be a way of making the
correct portion of that java class become a link target. There are
surely other interactions that must be specified.

> Can you use a URL to
> bind to the Java code implementing the flow object? How
> does the object declare its properties?

As far as the DSSSL spec goes: it just returns an error message if a
characteristic is set that it doesn't support. Of course a particular
implementation (for instance a GUI stylesheet editor) could use whatever
Java mechanisms it wants to get a list of supported characteristics.

You may also add characteristics to the default flow objects.

> I have in mind some very much more sophistocated kinds of
> flow objects. What I would like is a means to declare a
> declarative interface for these objects, which are then
> realized in Java.

(declare-flow-object-class formatting-instruction
  "UNREGISTERED::James Clark//Flow Object
Class::formatting-instruction")
 
> Finally has anyone done any work on an easier syntax for DSSSL?
> I can imagine recasting it in a more familiar syntax e.g. using
> expressions with operators perhaps closer to Java, or scripting
> languages. I suspect that this can be done using a trivial front
> end that maps to the scheme syntax.

I don't know of anyone who has done work on an infix syntax for DSSSL.
There are serious problems with infix's scalablility, but I definately
agree that for simple things and new users it is appropriate and more
inviting, so I too would be interested in such research. How does this
look:

#!/usr/local/bin/siod -v01,-m2 

main() := 
{writes(nil,"Hello Scheme World.\n");
 fflush(nil);
 writes(nil,"fib(20) = ",fib(20),"\n");
}
$

fib(x) := if x < 2 then x else fib(x-1) + fib(x-2)
$

That's the infix input to "Scheme in One Day", a simple Scheme
interpreter. I mention it because the job of translating scheme
constructs to infix would be already thought through (not that it is
very hard).

 Paul Prescod