Re: Side effects and large-scale conversion

[David Megginson <ak117@xxxxxxxxxxxxxxxxxxx>]

Chris:

The problem -- I suspect -- is that you are creatively abusing Jade.
A MIF-specific DSSSL formatting engine would maintain something like a
font and flag stack internally (say, in C, C++, or Java code) and
would restore the previous context automatically, as does Jade's RTF
backend.  DSSSL was not designed for dealing with low-level,
format-specific details in user code.

Given your current requirements, however, is there any way that you
could pass down context information using inherited characteristics?


-- David


Chris Maden writes:
 > [Sam Hunting]
 > > Has anyone ever used DSSSL for large-scale conversion (1000s of
 > > pages) -- doubtful -- and if so, did the prohibition of side effects
 > > get in the way?  Why or why not?
 > 
 > I converted 597 pages to MIF.
 > 
 > The lack of side effects is inconvenient due to the linear nature of
 > MIF.  Consider this DocBook fragment:
 > 
 > <Para>Then you can type <Literal>rm <Replaceable>options</Replaceable>
 > - -r</Literal> and get this:
 > <ProgramListing>
 > I ate all your files!
 > Ha ha ha!
 > </ProgramListing>
 > which isn't very good.</Para>
 > 
 > This needs to become the following, in English:
 > 
 > o Start a "Body" paragraph with no special font.
 > o Change to the "Literal" font.
 > o Change to the "Replaceable" font.
 > o Change to the "Literal" font.
 > o Change to the null font.
 > o End the current paragraph.
 > o Start a "CodeIndent" paragraph.
 > o End the current paragraph and start a new "CodeIndent" paragraph.
 > o End the current paragraph and start a "Body" paragraph.
 > o End the current paragraph.
 > 
 > The problem is the lack of a stack.  When I process the node for
 > <Replaceable>, I need to restore the MIF FTag to "Literal" when its
 > done.  But the Replaceable construction rule has no idea what to
 > restore its font to[*].  What I've done is, in the procedure that
 > handles mixed content[**], the current FTag is restored after
 > processing any inline element.  This is cumbersome, but not
 > impossible.  The same can be done with sub-paragraphs.
 > 
 > Anything that you might want side-effects for, you can do by making
 > the same decisions again from the current context.  This is unweildy
 > in the extreme, but not impossible.  Regard it as a challenge. (-:
 > 
 > - -Chris
 > 
 > [*] Yes, I could explicitly case all of its ancestors, and those of
 > all the other potential inline elements.  This would be extremely
 > painful.
 > [**] To escape special characters and to process SDATA entities into
 > their MIF equivalents.
 > - -- 
 > <!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
 > <!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
 > "<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
 > <USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
 > 
 >  DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist
 > 

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