Re: Issues with literate programming DSSSL Script

[Brandon Ibach <bibach@xxxxxxxxxxxxxx>]

Quoting Wroth, Mark <MARK.WROTH@xxxxxxxxxxx>:
> BI>    Keep in mind that the whole document is, essentially, parsed before
> BI> DSSSL processing begins.  So, just because you "skip" a section of the
> BI> document in your DSSSL script doesn't mean that it won't get parsed.
> 
> And I think I understand that the "bothersome" translations are happening in
> the parser, not in the DSSSL engine itself. Generally usually, a very
> helpful thing, as it removes all sorts of special cases from the DSSSL code.
> 
   Actually, the translations that you refer to are happening on the
*other* end of the line.  They are being done by the SGML backend as
it writes the FOT out.  This is why we can defeat them with the
formatting-instruction.  If you look at jade/TransformFOTBuilder.cxx,
line 550 (or so), in the [Open]Jade source, you'll see the loop that
writes out characters, and the special treatment of &, < and >.

> [... code section trimmed ...]
> 
> Since one of my goals for this project was to increase my understanding of
> DSSSL, I'll puzzle over your suggestion for a while ... it wasn't obvious to
> me at first reading, a fact I attribute to my ignorance rather than any
> fault of the code.
> 
   Well, to sum it up, the "breakup" function takes a single node-list
argument, which defaults to the children of the current node.  It goes
through all the nodes in this list, building up a list composed of
strings from the data-char nodes (so that each group of consecutive
characters becomes one string) and singleton node-lists for any
non-data-char nodes.  Thus, for the following:

<scrap id="abc">return(<scrapref id="def">);</scrap>

breakup would generate: ("return(" <node-list> ");")

where <node-list> is a node-list containing the single element node
corresponding to the <scrapref>, above.  We can now process this list
in order, using formatting-instructions to output the strings, and
process-node-list to handle everything else.  This is what the element
rule in the example does.

> >From a user perspective, it certainly would be nice to not have to "escape"
> relatively common symbols.  Failing to properly escape the significant
> punctuation (usually an "@") is one of the more common LP processor mistakes
> I make, and that's with a punctuation mark that's not real common in the
> languages I write.
> 
   As far as writing by hand, I guess it's just something to get used
to.  Any language has things like this that you need to learn.  I
wrote C for years, faithfully surrounding my strings with
double-quotes, only to have to learn to use single-quotes, instead,
when I started doing a lot of SQL.  And every now and then, I throw
myself a real curve ball when Postscript makes me use parens for
strings. :)
   Of course, if your user is using a decent text editor (like vi :),
you could set up key mappings to make this easier.  For instance, map
&, < and > to insert the appropriate entity references, and map some
other keys to allow the user to generate tags and entity references
(where they'd need the actual characters).  Just a possibility... :)

-Brandon :)


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