RE: About columns?

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

HI Matthias,

> Matthias said:
> --------------------------------------------------------
> The trick here would be to implement page-sequence and
column-set-sequence.
> Unfortunately, nobody found it yet...
>
> Didier says:
> -------------------------------------------------------
> I agree that this would be a solution and that this solution is not
> necessarily obvious. Speaking more particularly of the way to implement
> column-set-sequence, Nisheet (Netscape) reminded me that a non standard
> feature in Mozilla allows colum rendition. It may (I just said may) be
> possible to implement the colum-set-sequence object with the Mozilla
column
> rendition object. However, when I tried on paper a complex layout with
> page-model and column-set-sequence, the Mozilla engine, even using the
area
> object (i.e. a CSS box object) is not sufficient. Now the question is: up
to
> where the DSSSL visual object model is implementable with current Open
> source rendition engines. I someone has any answer please stand up. For my
> part, I am at the beginning of my exploration.

Matthias answer:
--------------------------------------------------------
I guess the jades nonstandard ICs for column rendition pretty much cover
the possibilities.

Didier said:
----------------------------------------------------------
>  Off course, in that case, the possible rendition capabilities are with
the
> Mozilla rendition objects (all objects are based on the block CSS model).
To
> fully use the rendition capabilities of the engine, this would require us
to
> fully implement the html backend and add new characteristics (like for
> instance background-color)

Matthias answer:
-----------------------------------------------------------
It may be simpler to write a new backend that directly goes
FOT->Mozilla rendition objects. But improving the html backend would
of course still be a laudable project.


Didier says:
---------------------------------------------------------
The problem is that, on a first version, we will have difficulties to
include the code directly in the Gecko engine. However, as I demonstrated
with the SGML/XML kit, it is feasible to place the code as a MIME filter.
Basically what the MIME filter does is to receive the stream before any
processing done at the Gecko engine level. Then, it process the stream (i.e.
transform it into HTML). The output stream is given to Mozilla as an HTML
stream and this latter is interpreted and displayed. This kind of
implementation also, as the advantage that style routing could be
implemented. For instance, the MIME filter can check for the style PI and
then based on the "type" attribute, redirect the control to the appropriate
transformation engine.

So as goal one to reach: an OpenJade MIME filter engine .I discussed about
this issue with Netscape since the last 7 months - we got several conference
calls with Keith Visco from MITRE, who is providing an XSL engine, Nishteet
and me about how to include transformation engines into Mozilla. We asked
(Keith and me) for some modifications into the Netlib module so that the
concept of MIME filters could be implemented. The Netlib group (now renamed)
re-created the module so that a cascade of MIME filters can process an
incoming stream before the stream is processed by the HTML interpreter.

as a second goal, to modify the parsing level (an document handling  XPCOM
module off course) in Mozilla, and have a backend using directly the Gecko
rendition objects. However, this requires to modify the incoming stream
parser and implement a "router" based on the MIME type (not the same thing
as the MIME filter, it is a level above that), then based on the document
type have the right parser/rendition (i.e. document handler) engine loaded
and the document processed.

It appears that, if we have good html support (i.e. a working html backend)
then, the code could be included in Mozilla without any structural change.
This implies that the next version of Mozilla could include a DSSSL
transformation engine. But, actually missing in the html backend, we count:
- rule
- table
- background color and image characteristics (for paragraph, sequence, and
maybe display-group)
- a need for a script object
- a need for an applet/plug-in object
- column (maybe but not portable on other browsers)

Otherwise, DSSSL cannot be reasonably used for on-line device. So, if we
where to do a modern DSSSL-O requirement, this would imply that we just look
at what's required to have a DSSSL engine to leverage the objects already
present in browsers. It appeared from the phone discussions that one of the
perceived strength of XSL is the ability to already include all HTML
objects. What seemed interesting of DSSSL though, is that a set of flow
objects provide a level of abstraction to the underlying objects. For
instance, to be able to create (i.e. make) a paragraph object translated
into a DIV/SPAN set for on-line rendition and to a printed paragraph on
paper is perceived as useful. A single object (the paragraph) and hence a
single script for difference output devices. On the other hand, XSLT is
tightly coupled to HTML and do not provides this level of independency.
XSLFO does it but no actual implementations can do it. OpenJade is month
ahead in terms of code to reach that goal.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


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