Re: (dsssl) How to make a RTF styles-sheet with DSSSL?

Subject: Re: (dsssl) How to make a RTF styles-sheet with DSSSL?
From: Brandon Ibach <bibach@xxxxxxxxxxxxxx>
Date: Sat, 9 Mar 2002 18:32:36 -0600
Quoting Javier Farreres de la Morena <spanish@xxxxxxxxx>:
> >My problem is more complex. In fact, I have a title and some paragraph
> >to group in one box:
> ><par>Normal paragraph without box</par>
> ><par type="title">A TITLE in the box</par>
> ><par type="box">paragraph 1 in the box</par>
> ><par type="box">paragraph 2 in the box</par>
> ><par type="box">paragraph 3 in the box</par>
> ><par>Normal paragraph without box</par>
> >How can I group the title and the three paragraphs in a single box with
> >black borders?
> 
> This is here where the problem comes. This markup means nothing, as everything
> is a par element, and noone assures you that all box elements end up together.
> Also, does each par box have a box alone of they are grouped together in
> the same box? The GOOD markup would be:
> 
   The markup means *something*.  The trick is to come up with some
rules to determine what it means, given the rather loose markup model.

> ><par>Normal paragraph without box</par>
> <box>
> ><type>A TITLE in the box</title>
> ><par>paragraph 1 in the box</par>
> ><par>paragraph 2 in the box</par>
> ><par>paragraph 3 in the box</par>
> </box>
> ><par>Normal paragraph without box</par>
> 
> And obtaining this markup from the source you have provided before is an
> easy matter with a good transformation tool. And again, it will allow you
> to define a governing DTD.
> Bad luck for you, DSSSL transformation language would do it for you, but
> it is not yet implemented for OpenJade.
> 
   While the DSSSL TL is very powerful, and a sad omission from
current implementations, Jade's SL-based transformations are quite
capable, as well.  In fact, within the realm of SGML-to-SGML (or
XML-to-XML, etc), there are relatively few things that the TL can do
that can't also be done with Jade's SL and SGML backend.
   For this case, something like the following should work (untested,
of course... let me know if it doesn't):

      (element PAR
        (cond
          ((string=? "title" (attribute-string "TYPE"))
           (make box
             (make paragraph (process-children))
             (let loop ((nl (rsiblings (current-node)))
                        (found? #f) (res (empty-sosofo)))
               (let ((fn (node-list-first nl)))
                 (cond
                   ((not found?) (loop (node-list-rest nl)
                                       (node-list=? fn (current-node)) res))
                   ((string=? "box" (attribute-string "TYPE" fn))
                    (loop (node-list-rest nl) #t
                      (sosofo-append res 
                          (make paragraph (process-node-list (children fn))))))
                   (else res))))))
          ((string=? "box" (attribute-string "TYPE"))
           (empty-sosofo))
          (else (make paragraph (process-children)))))

   This assumes that any sequence of one or more "box" <par>s is
preceded by by a "title" <par>.  If not, the "box" <par>s will just be
skipped.  If this is a possible situation, the code would need to be
modified to handle it.

> >I am generating RTF documents from an SGML file.
> >Does anyone can give me examples to make box flow object?
> 
> Well, for the markup you use it can be complicated. You would need the query
> feature to obtain all the par element with type set to title, followed by
> several par elements which are together and have the attribute type to box,
> and process all of them with a single style rule but it is not yet implemented
> in OpenJade, as long as I know. This query would best be implemented with
> node regexp expressions, which are also not implemented in OpenJade.
> 
   No, no and yes.  No, he would not need the query feature.  In fact,
I don't think you really understand what the query feature is.  The
query feature allows you to specify a processing rule which matches
nodes using an arbitrary query language expression.  The nodes are
still processed just one at a time.  No processing rule has more than
one "current node", ever.  Processing more than one node in a single
invocation of a rule is done by fetching the other nodes using query
language expressions, as demonstrated above.
   As for node regexps, I think you attach far too much importance to
them.  They are simply a higher-level mechanism for querying the
grove, just as traditional text regexps are just a higher level
mechanism for matching text patterns.
   Any grove querying you could ever want to do can be accomplished
with just seven procedures, all of which have been in Jade since the
beginning: (current-node), (node-property), (node-list), (node-list=?),
(node-list-empty?), (node-list-first) and (node-list-rest).  (It may
be possible to argue that there should be other entries in this list,
but this covers pretty much everything.)  With these primitives,
anything can be done, and all other procedures can be defined in terms
of these.
   Jade's grove querying capabilities are not nearly as crippled as
you seem to think they are.

> Anyway I must say that in my oppinion this is perverting the use of SGML.
> You should strive to mark up the meaning of your information, not the format
> of it. I mean, what is codifying this box? This is the important thing.
> I suppose it is not affordable to convert the work of your external collaborators
> to using SGML as their base tools, rather than Word and RTF format. But
> if you have a governing DTD defined by you, their work and yours would be
> much easier altogether.
> 
   I'm sure many of us would like to have better-designed DTDs and
better encoded data.  We'd also like 5 minute work weeks and an end to
world hunger. ;)  In the meantime, how about a focus on solutions to
problems using what we have?

-Brandon :)

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

Current Thread